-
-
Notifications
You must be signed in to change notification settings - Fork 594
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
(alias) Breaking feature: built-in resolving algorithm is replaced in favor of Rollup's this.resolve()
#34
Conversation
According to pnpm actual version and included packages
Allow to use customResolver instead of built-in resolving algorithm in
customResolver option
customResolver description
@@ BREAKING @@ And replaced by Rollup's context function `this.resolve()`
Hi @shellscape, may you invite others to review this PR? |
Done! I've added @Andarist and @lukastaegert to review. |
Thanks! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The production code appears good to me as it is, but I have profound suggestions for how to improve the tests and make them more realistic. Also, you should run pnpm run lint
, your changes cause a lot of linter warnings.
@@ -144,79 +114,26 @@ test('Leaves entry file untouched if matches alias', (t) => { | |||
t.is(resolved, null); | |||
}); | |||
|
|||
test('Test for the resolve property', (t) => { | |||
const result = alias({ | |||
resolve: ['.js', '.jsx'], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As I understand, this flag has been removed, but it is still referenced in the Readme. It would be nice to update the readme to
- remove this
- mention that this plugin will use the resolver plugins specified for Rollup, and that if you rely on Node specific features, you probably want rollup-plugin-node-resolve in your setup
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done. Please find changes in latest version.
}); | ||
|
||
const resolved = result.resolveId('resolve', '/src/import.js'); | ||
|
||
t.is(resolved, 'i/am/a/file'); | ||
}); | ||
|
||
test('i/am/a/local/file', (t) => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Again, it would be interesting to reintroduce these as integration tests involving Rollup and possibly rollup-plugin-node-resolve. Actually I think it would be nice to run ALL tests through Rollup, this would make the tests much more realistic and we could also get rid of the customResolve: x => x
that needed to be introduced into many tests to keep the structure. Here is a helper that would work:
// "plugins" is an array of plugins for Rollup, they should include "alias"
// "tests" is an array of pairs [importee, importer]
function resolveWithRollup(plugins, tests) {
return new Promise((resolve, reject) => {
rollup({
input: 'dummy-input',
plugins: [
{
name: 'test-plugin',
buildStart() {
resolve(
// The buildStart hook is the first to have access to this.resolve
// We map the tests to an array of resulting ids
Promise.all(
tests.map(([importee, importer]) =>
this.resolve(importee, importer).then(({ id }) => id)
)
)
);
},
resolveId(id) {
if (id === 'dummy-input') return id;
return null;
},
load(id) {
if (id === 'dummy-input') return 'console.log("test");';
return null;
}
},
...plugins
]
// if Rollup throws an error, this should reject the test
}).catch(reject);
});
}
// convenience function for just injecting the alias plugin
function resolveAliasWithRollup(aliasOptions, tests) {
return resolveWithRollup([alias(aliasOptions)], tests);
}
Here is an example test, rewritten using the helper:
test('Simple aliasing (array)', (t) =>
resolveAliasWithRollup(
{
entries: [
{ find: 'foo', replacement: 'bar' },
{ find: 'pony', replacement: 'paradise' },
{ find: './local', replacement: 'global' }
]
},
[
['foo', '/src/importer.js'],
['pony', '/src/importer.js'],
['./local', '/src/importer.js']
]
).then((result) => t.deepEqual(result, ['bar', 'paradise', 'global'])));
For tests involving the alias plugin and other plugins, the first helper could be used.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for detailed example. I was thinking in same way, but stopped at dilemma: to include rollup-plugin-node-resolve or not. My point is that it is not a good idea to include 3rd party plugin into alias
plugin tests as it is not reliable in long-term. But right now i do not see any better option to keep tests coverage at good level without doing it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably it would be better to include rollup-plugin-node-resolve after #32 is merged. However it does not block other changes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done. Please find changes in latest version.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My point is that it is not a good idea to include 3rd party plugin into alias plugin tests as it is not reliable in long-term
It will make the test slightly less stable, but as rollup-plugin-node-resolve is an important pillar of the Rollup ecosystem, it will basically improve consistency of the wider ecosystem, which I would love very much.
Probably it would be better to include rollup-plugin-node-resolve after #32 is merged
That would definitely make it easier, but I am not sure how long this will take, this is not a trivial move. If you reference the external plugin for now, we should just not forget to change the reference once #32 is merged. Should not be a big change, but this does not need to be coupled.
# Conflicts: # packages/alias/test/test.js
Tests: every test is done by invoking Rollup instance; Plugin: fixed according to linter warnings; Readme: updated.
this.resolve()
this.resolve()
packages/alias/README.md
Outdated
@@ -52,7 +54,7 @@ module.exports = { | |||
dir: 'output', | |||
format: 'cjs' | |||
}, | |||
plugins: [alias({ resolve: ['.jsx', '.js'] })] | |||
plugins: [alias()] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
would be good to include example usage here
packages/alias/test/test.js
Outdated
@@ -10,6 +10,47 @@ import alias from '../dist'; | |||
const normalizePath = (pathToNormalize) => slash(pathToNormalize.replace(/^([A-Z]:)/, '')); | |||
const DIRNAME = normalizePath(__dirname); | |||
|
|||
// "plugins" is an array of plugins for Rollup, they should include "alias" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
could you convert those 2 lines to a JSDOC? that way this function would get nice hints in IDEs
packages/alias/test/test.js
Outdated
{ find: './local', replacement: 'global' } | ||
] | ||
}, | ||
[['foo', '/src/importer.js'], ['pony', '/src/importer.js'], ['./local', '/src/importer.js']] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Personally would prefer for a single test to be an object ({ requester, importSource }
or similar) rather than a tuple, but if you prefer tuples I won't insist on this one.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed, makes the test probably a bit more readable. Maybe stick with the terminology used in Rollup's docs: https://rollupjs.org/guide/en/#resolveid which would be {source, importer}
Hi, @Andarist, @lukastaegert, please find new changes here according all mentioned points. |
@Acionyx we won't let this one fall off the radar. sometimes it takes them a few days to circle back. |
@Andarist @lukastaegert please put your peepers back on this one when you have the chance. |
@Acionyx we've got an approval to merge. We'll need you to update rm pnpm-lock.yaml
git merge upstream/master
pnpm install --force Should get it back to mergable. |
Thanks to everyone for working on this one. Please have patience for a new major version. We're going to try to get our publishing tools setup to automate this. |
Hi @shellscape, thanks for catching up with this and helping with conflicts. Thanks all, hope those changes will be warmly met by community :) |
This PR contains:
Are tests included?
Breaking Changes?
Related issues
#14
#12
Description
So, after short discussion with @lukastaegert we agreed that at least this feature should be discussed with community.
This feature enables default resolving behaviour for Alias plugin.
The reasons:
customResolver
was implemented, it was impossible to create some complex Rollup configurations with Alias plugin.customResolver
was implemented, it seems logical to remove any hidden resolving logic.Overall simplicity and transparent behavior are key for good plugin as i think.