Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

node-resolve: simplify builtins and remove customResolveOptions #656

Merged
merged 23 commits into from Nov 30, 2020

Conversation

tjenkinson
Copy link
Member

@tjenkinson tjenkinson commented Nov 21, 2020

Rollup Plugin Name: node-resolve

This PR contains:

  • bugfix
  • feature
  • refactor
  • documentation
  • other

Are tests included?

  • yes
  • no

Breaking Changes?

  • yes
  • no

If yes, then include "BREAKING CHANGES:" in the first commit message body, followed by a description of what is breaking.

Description

Note this includes #637

This PR upgrades resolve to the next version which includes the includeCoreModules option.

We are no longer relying on our builtins list to agree with resolve's. If we decide it's a builtin, it's a builtin, otherwise we hand off to resolve which will never treat it as a builtin. This meant we could remove a block of code that was there just to make sure resolve didn't treat something as a builtin if it had the same name.

It also makes some other general changes such as moving the use of resolve and the filter for resolve into resolveImportSpecifiers and returning

{
  location,
  hasModuleSideEffects,
  hasPackageEntry,
  packageBrowserField,
  packageInfo
}

from this function instead of just the location. Previously the resolve options were passed down to resolveImportSpecifiers() and the filter was in index, along with the other variables which were updated as a side effect of the filter running.

There should be no functional changes, other than the removal of customResolveOptions mentioned below.

Breaking changes

I removed customResolveOptions and added moduleDirectories (which used to be customResolveOptions.moduleDirectory). My reasoning for this was

  • so that we aren't coupling the api of node-resolve to resolve
  • because if a user replaced some of the resolve options it would actually break the plugin. If the user added their own filter for example ours wouldn't run
  • Overriding an option like resolveSymlinks doesn't make sense IMO when rollup itself has the same option, and we also inherit from that anyway.

I'm not sure what other options other than moudleDirectory users might want to use, but I think if it turns out a user is using one of the other options, we could add it back as a top level option.

Also I removed the only option, which was already marked as deprecated.

@tjenkinson tjenkinson marked this pull request as ready for review November 21, 2020 16:42
Copy link
Member

@lukastaegert lukastaegert left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code-wise, I think this looks good, thanks for taking this up! I had some comments mostly with regard to documentation, would be nice if you could use this PR to also make sure documentation, types and code are in sync.

@@ -33,6 +33,7 @@ module.exports = {
'import/no-namespace': 'off',
'import/no-named-export': 'off',
'no-unused-vars': 'off',
'spaced-comment': 'off',
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it really necessary to mess with global linting rules? If there is really a good reason to ignore it at some point, rather use a // eslint-disable-next-line spaced-comment.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There seems to be a bug with this rule and '.d.ts' files. I tried a lot of things to make it work, including

/* eslint-disable spaced-comment */

in the file but it seems to ignore it :/

Whenever it tries to 'fix' the lint errors it ends up inserting random spaces everywhere and then still fails for a different reason.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If it only affects d.ts files, then I would recommend adding it as an override:

overrides: [
  files: ['**/*.d.ts'],
  rules: [{'spaced-comment' : 'off'}]
]

moduleDirectory: 'js_modules'
}
```
Directory in which to recursively look for modules.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there still a way to modify the preserveSymlinks option? Of all remaining resolve options, I think this one is really important as some people with uncommon package systems rely on it.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, I guess the option still exists in the code but is not documented. Do you think you might add it here, because I fear for lack of documentation, some people might have used the customResolveOptions for that.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeh it always inherits the rollup one now. I added this to the readme.

packages/node-resolve/test/types.ts Show resolved Hide resolved
@@ -62,18 +62,12 @@ Default: `false`

If `true`, instructs the plugin to use the `"browser"` property in `package.json` files to specify alternative files to load for bundling. This is useful when bundling for a browser environment. Alternatively, a value of `'browser'` can be added to the `mainFields` option. If `false`, any `"browser"` properties in package files will be ignored. This option takes precedence over `mainFields`.

### `customResolveOptions`
### `moduleDirectory`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Despite the singular name, moduleDirectory can actually be an array in resolve. We use this extensively as we have some modules installed via bower, so we set this to `['node_modules', 'bower_components'].

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks. Will make this clear

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

pushed commit for this

@LarsDenBakker
Copy link
Contributor

LarsDenBakker commented Nov 23, 2020

Would be it be worth doing some backwards compatibility work by reading the old customResolveOptions object and mapping them to the new properties? Lately rollup plugins have a breaking change every other week, which places extra burden on consumers to keep up.

If that's not possible we might need to consider saving up this breaking change, since breaking for a refactor isn't great.

@tjenkinson
Copy link
Member Author

Would be it be worth doing some backwards compatibility work by reading the old customResolveOptions object and mapping them to the new properties? Lately rollup plugins have a breaking change every other week, which places extra burden on consumers to keep up.

Was wondering this. Happy to add aliases and a warning for the options that still exist.

If that's not possible we might need to consider saving up this breaking change, since breaking for a refactor isn't great.

There is already another major change ready to go: #627

Which I was hoping we could batch together.

@lukastaegert
Copy link
Member

I guess it still makes sense to alias the old options to reduce friction. In that case, we should also have a warning that instructs people to use the new options.

@tjenkinson
Copy link
Member Author

Added a deprecation warning for customResolveOptions.moduleDirectory and made it an alias for moduleDirectories.

For the rest of the options it throws an error now.

tjenkinson and others added 2 commits November 28, 2020 11:02
looks like auto lint messed up
@shellscape shellscape merged commit 23b0bf7 into rollup:master Nov 30, 2020
vasttiankliu added a commit to vasttiankliu/plugins that referenced this pull request Nov 17, 2022
…ptions` (#656)

BREAKING CHANGES: See rollup/plugins#656

* refactor handling builtins

* remove duplicate code block

* do not warn when using a builtin when no local version

* add not about warnings to readme

* update node-resolve, use `includeCoreModules`, and simplify

this also removes `customResolveOptions` and adds `moduleDirectory`

* remove console log

* remove deprecated `only` option

* remove `only` from types

* update types test

* lint index.d.ts

* disable spaced-comment rule because it's breaking on .d.ts files

* mention rollup `preserveSymlinks` option in readme

* moduleDirectory => moduleDirectories

* put filter in config object directly

* add missing options to types.ts

* add deprecation warnings/errors

* handle deprecations in separate file

* move catch closer to error

* revert commonjs changes

looks like auto lint messed up

* remove old comment

Co-authored-by: Andrew Powell <shellscape@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants