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

(alias) Breaking feature: built-in resolving algorithm is replaced in favor of Rollup's this.resolve() #34

Merged
merged 16 commits into from
Dec 16, 2019

Conversation

Acionyx
Copy link
Contributor

@Acionyx Acionyx commented Nov 10, 2019

  • Rollup Plugin Name: alias

This PR contains:

  • bugfix
  • feature
  • refactor
  • documentation
  • other

Are tests included?

  • yes (bugfixes and features will not be merged without tests)
  • no

Breaking Changes?

  • yes (breaking changes will not be merged unless absolutely necessary)
  • no

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:

  1. Alias plugin is made for 'aliasing', not for 'resolving';
  2. Before customResolver was implemented, it was impossible to create some complex Rollup configurations with Alias plugin.
  3. After 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.

@Acionyx
Copy link
Contributor Author

Acionyx commented Nov 16, 2019

Hi @shellscape, may you invite others to review this PR?
I would like to make final fixes, changes to Readme, etc, if the main idea of this PR is accepted and has sense.

@shellscape
Copy link
Collaborator

Done! I've added @Andarist and @lukastaegert to review.

@Acionyx
Copy link
Contributor Author

Acionyx commented Nov 16, 2019

Done! I've added @Andarist and @lukastaegert to review.

Thanks!

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.

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.

packages/alias/test/test.js Show resolved Hide resolved
@@ -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'],
Copy link
Member

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

Copy link
Contributor Author

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) => {
Copy link
Member

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.

Copy link
Contributor Author

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.

Copy link
Contributor Author

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.

Copy link
Contributor Author

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.

Copy link
Member

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.
@Acionyx Acionyx changed the title WIP: (alias) Breaking feature: built-in resolving algorithm is replaced in favor of Rollup's this.resolve() (alias) Breaking feature: built-in resolving algorithm is replaced in favor of Rollup's this.resolve() Nov 17, 2019
@@ -52,7 +54,7 @@ module.exports = {
dir: 'output',
format: 'cjs'
},
plugins: [alias({ resolve: ['.jsx', '.js'] })]
plugins: [alias()]
Copy link
Member

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

@@ -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"
Copy link
Member

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

{ find: './local', replacement: 'global' }
]
},
[['foo', '/src/importer.js'], ['pony', '/src/importer.js'], ['./local', '/src/importer.js']]
Copy link
Member

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.

Copy link
Member

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}

@Acionyx Acionyx requested a review from Andarist November 24, 2019 22:02
@Acionyx
Copy link
Contributor Author

Acionyx commented Nov 24, 2019

Hi, @Andarist, @lukastaegert, please find new changes here according all mentioned points.

@shellscape
Copy link
Collaborator

@Acionyx we won't let this one fall off the radar. sometimes it takes them a few days to circle back.

@shellscape
Copy link
Collaborator

@Andarist @lukastaegert please put your peepers back on this one when you have the chance.

@shellscape
Copy link
Collaborator

@Acionyx we've got an approval to merge. We'll need you to update pnpm-lock.yaml however. With our monorepo setup that sometimes gets too far out of sync and can't be merged:

rm pnpm-lock.yaml
git merge upstream/master
pnpm install --force

Should get it back to mergable.

@shellscape
Copy link
Collaborator

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.

@Acionyx
Copy link
Contributor Author

Acionyx commented Dec 17, 2019

Hi @shellscape, thanks for catching up with this and helping with conflicts.

Thanks all, hope those changes will be warmly met by community :)

This was referenced Jan 3, 2020
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.

4 participants