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

Aliases provided in a <link> tag for a Svelte 3 file aren't resolved by known build-system aliases #679

Closed
stffrd opened this issue Oct 25, 2019 · 2 comments · Fixed by #681
Closed

Comments

@stffrd
Copy link
Contributor

@stffrd stffrd commented Oct 25, 2019

O' LORD OF MODULAR CSS.

I'm running into an issue where I'd like to use the aliases that my current rollup configuration knows about to point to a specific css file to use in a given Svelte3 component.

like so:
<link rel="stylesheet" href="shared/styles/target.css">

Normally the way I structure the css is by referencing a stylesheet in the same general directory as the component, such that referencing is as simple as
<link rel="stylesheet" href="./target.css">

However, again, I'm running into the issue when I try to use aliases that my rollup configuration knows about.

Expected Behavior

<link rel="stylesheet" href="shared/styles/target.css"> is resolved properly to point to the correct file, where shared/ is a convenient alias pointing to another folder in my project.

Current Behavior

<link rel="stylesheet" href="shared/styles/target.css"> causes an error :

[!] (plugin svelte) Error: Cannot find module 'shared/styles/target.css'

Possible Solution

The resolution of a given href should probably be injected with known build time aliases (or at least the resolver should expose an option to provide it with a pairing of aliases to paths to resolve against)

@tivac
Copy link
Owner

@tivac tivac commented Oct 25, 2019

Looks like this line

const external = resolve(path.dirname(html), css);

Should actually use the Processor instance's ._resolve() method instead of bare resolve-from. ._resolve() should also be renamed to .resolve() so it's available to any API consumers that want it.

this._resolve = resolve.resolvers(options.resolvers);

tivac added a commit that referenced this issue Oct 29, 2019
Fixes #679 by allowing the svelte preprocessor to use the same file resolution logic that the modular-css processor is using.
tivac added a commit that referenced this issue Oct 29, 2019
Fixes #679 by allowing the svelte preprocessor to use the same file resolution logic that the modular-css processor is using.
tivac added a commit that referenced this issue Oct 29, 2019
Fixes #679 by allowing the svelte preprocessor to use the same file resolution logic that the modular-css processor is using.
@tivac tivac closed this in #681 Oct 29, 2019
tivac added a commit that referenced this issue Oct 29, 2019
* feat(processor): expose processor.resolve()

And update the tests that were already using the `._resolve()` version.

* fix(svelte): use processor.resolve()

Fixes #679 by allowing the svelte preprocessor to use the same file resolution logic that the modular-css processor is using.
@tivac
Copy link
Owner

@tivac tivac commented Oct 30, 2019

This is fixed in @modular-css/svelte@25.2.0

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

Successfully merging a pull request may close this issue.

2 participants