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

Support Webpack Resolver Plugins in Loader #658

Closed
alanwright opened this issue Aug 19, 2020 · 1 comment
Closed

Support Webpack Resolver Plugins in Loader #658

alanwright opened this issue Aug 19, 2020 · 1 comment

Comments

@alanwright
Copy link

@alanwright alanwright commented Aug 19, 2020

Describe the feature

Currently the linaria/loader uses enhanced-resolve for file resolution. It currently takes the webpack Resolve.options.alias and Resolve.options.module from the webpack.config however it doesn't take the Resolve.options.plugins. It would be great to support plugins here as well. I'd be interested to hear if leaving this out was intentional due to resolution issues, or just not yet required.

Motivation

A project I am attempting to adopt linaria in has a custom resolver plugin for imports of the style :project. For example, :themes/styles/utils/getSize will resolve to src/themes/styles/utils/getSize. The ":" is shorthand for the /src/ folder. This monorepo is quite large, so adopting a new import pattern would be a large change.

Possible implementations

The existing enhanced-resolve creation could also pass along plugins:

linaria/src/loader.ts

Lines 66 to 79 in 47c8157

const resolveSync = enhancedResolve.create.sync(
// this._compilation is a deprecated API
// However there seems to be no other way to access webpack's resolver
// There is this.resolve, but it's asynchronous
// Another option is to read the webpack.config.js, but it won't work for programmatic usage
// This API is used by many loaders/plugins, so hope we're safe for a while
this._compilation?.options.resolve
? {
...resolveOptions,
alias: this._compilation.options.resolve.alias,
modules: this._compilation.options.resolve.modules,
}
: resolveOptions
);

const resolveSync = enhancedResolve.create.sync(
// this._compilation is a deprecated API
// However there seems to be no other way to access webpack's resolver
// There is this.resolve, but it's asynchronous
// Another option is to read the webpack.config.js, but it won't work for programmatic usage
// This API is used by many loaders/plugins, so hope we're safe for a while
this._compilation?.options.resolve
  ? {
      ...resolveOptions,
      alias: this._compilation.options.resolve.alias,
      modules: this._compilation.options.resolve.modules,
+   plugins: this._compilation.options.resolve.plugins,
    }
  : resolveOptions
);

Or it could be specified through linaria/loader options, though this would deviate from the existing pattern for alias/modules.

I am happy to help with this change if it's a good first issue.

Related Issues

#630

@alanwright
Copy link
Author

@alanwright alanwright commented Aug 19, 2020

This can be solved using @babel-plugin-module-resolver as it supports more flexibility than webpack aliases. We already had a plugin in our webpack config, so onboarding would've been easier if plugins were already included.

Since there is a workaround after finding #630 and @babel-plugin-module-resolver feel free to close if plugins shouldn't be supported. I will +1 #630 for documentation that would've made it easier to find this

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant