node-resolve: simplify builtins and remove customResolveOptions#656
node-resolve: simplify builtins and remove customResolveOptions#656shellscape merged 23 commits intorollup:masterfrom
customResolveOptions#656Conversation
…resolve-refactor-builtins
this also removes `customResolveOptions` and adds `moduleDirectory`
lukastaegert
left a comment
There was a problem hiding this comment.
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.
| 'import/no-namespace': 'off', | ||
| 'import/no-named-export': 'off', | ||
| 'no-unused-vars': 'off', | ||
| 'spaced-comment': 'off', |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
If it only affects d.ts files, then I would recommend adding it as an override:
overrides: [
files: ['**/*.d.ts'],
rules: [{'spaced-comment' : 'off'}]
]
packages/node-resolve/README.md
Outdated
| moduleDirectory: 'js_modules' | ||
| } | ||
| ``` | ||
| Directory in which to recursively look for modules. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Yeh it always inherits the rollup one now. I added this to the readme.
packages/node-resolve/README.md
Outdated
| 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` |
There was a problem hiding this comment.
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'].
There was a problem hiding this comment.
Thanks. Will make this clear
There was a problem hiding this comment.
pushed commit for this
|
Would be it be worth doing some backwards compatibility work by reading the old If that's not possible we might need to consider saving up this breaking change, since breaking for a refactor isn't great. |
Was wondering this. Happy to add aliases and a warning for the options that still exist.
There is already another major change ready to go: #627 Which I was hoping we could batch together. |
|
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. |
|
Added a deprecation warning for For the rest of the options it throws an error now. |
looks like auto lint messed up
…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>
…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>
Rollup Plugin Name:
node-resolveThis PR contains:
Are tests included?
Breaking Changes?
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
resolveto the next version which includes theincludeCoreModulesoption.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 toresolvewhich will never treat it as a builtin. This meant we could remove a block of code that was there just to make sureresolvedidn'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
resolveand the filter for resolve intoresolveImportSpecifiersand returningfrom this function instead of just the location. Previously the
resolveoptions were passed down toresolveImportSpecifiers()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
customResolveOptionsmentioned below.Breaking changes
I removed
customResolveOptionsand addedmoduleDirectories(which used to becustomResolveOptions.moduleDirectory). My reasoning for this wasresolveresolveoptions it would actually break the plugin. If the user added their own filter for example ours wouldn't runresolveSymlinksdoesn'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
moudleDirectoryusers 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
onlyoption, which was already marked as deprecated.