aliases as a separate config object

[ChristopherBiscardi]

This is an alternate version of #237 that reflects the object changes discussed in #236 . It is smaller and more distinct, so as to not overlap functionality with webDependencies. Instead of modifying the type signature for webDependencies, this PR adds a new, distinct aliases key. The aliases key is almost a verbatim passthrough to rollup-plugin-alias. The additional logic is for adding aliases to the importMap with the proper names.

{
  "snowpack": {
    "aliases": {
      "react": "preact/compat"
    }
  }
}

TODO: add alias tests if this object approach is preferred over the arrays/webDependencies one.

[FredKSchott]

This is great! One thing that's missing: our auto import scanning will detect the use of the alias, but installTargets needs the actual package. So just make sure that you're checking aliases inside the import scanner, and properly adding them to installTargets.

[ChristopherBiscardi]

This is great! One thing that's missing: our auto import scanning will detect the use of the alias, but installTargets needs the actual package. So just make sure that you're checking aliases inside the import scanner, and properly adding them to installTargets.

I'm not entirely sure what is meant by this with respect to the auto-import scanner. For example: it doesn't seem like dependencies-of-dependencies get scanned for imports, even without aliases. So react-helmet imports react but react never ends up in the import-map anyway.

[FredKSchott]

Okay here's the use-case I'm picturing. I haven't run this PR yet, so there's also a chance that this just isn't an issue:

1. I use the config "aliases": {"react": "preact/compat"}
2. In my code, I have import React form 'react' or import React form '/web_modules/react.js'
3. I run `npx snowpack --include "src/**/*.js"
4. Snowpack analyzes my "react" import, but still correctly installs node_modules/preact/compat instead of node_modules/react

[jmchuster]

since webDependencies is now a top-level entry, i think it would actually be really slick to have this be webAliases as a top-level entry

[FredKSchott]

@ChristopherBiscardi just fixed merge conflicts for you, although you may need to run npm run format to get the latest prettier updates to pass linting.

There's still just that one outstanding question about the import scanner to get this over the line. Let me know if you'd like any help.

[ChristopherBiscardi]

npx snowpack --include "src/**/*.js works without changes to this PR with the following config:

  "snowpack": {
    "aliases": {
      "react": "preact/compat",
      "react-dom": "preact/compat"
    }
  }

[FredKSchott]

Awesome! This looks good to merge, failing tests are on master which I'm in the middle of cleaning up now

[ChristopherBiscardi]

@FredKSchott Any chance of this getting released in the 1.7.x line? or is this going to be a 2.0 only thing now?

[AlexGalays]

@FredKSchott This doesn't handle aliases for local imports, right? It's quite a common thing to do with webpack/rollup and TypeScript, e.g:

Aliasing app/* to ./src/*.

Looks like snowpack assumes it's a node_modules package and must have a package.json

[FredKSchott]

@ChristopherBiscardi whoops, missed your message. Yes, happy to get this out in the v1.x branch if you'd like.

@AlexGalays currently it's only for dependencies. I'm not opposed to adding some sort of simple 'baseUrl' type behavior for developers who want this, but we also have to be careful about how much 'sugar' like this that we support, since import 'app/* is technically saying "import this file from inside the 'app' npm package".

Is there some way to write this sort of import that wouldn't be interpreted as an npm package?

[AlexGalays]

I'm seeing good results with babel-plugin-module-resolver. Everyone is happy as the path starts with a /!

[FredKSchott]

@ChristopherBiscardi just tried to cherry-pick, but there were more conflicts than expected. happy to look at a PR that merges this work into the v1.x branch, but otherwise i'm going to need to focus my time on getting v2 out the door later this week / early next week.

[niltonvasques]

@AlexGalays I tried to use module-resolver here, but it only works if I rename the imports after the dev server has started, if I rename before, the snowpack install crashing with a missing import message.

babel

  "plugins": [
    ["module-resolver", {
      "root": ["./"],
      "alias": {
        "^@css/(.+)": "./src/static/css/\\1"
      }
    }]
  ]

Crash:

Snowpack

  Server starting…

  mount:web_modules.......[READY] mount $WEB_MODULES --to /web_modules
  mount:public............[READY] mount public --to /
  mount:src...............[READY] mount src --to /_dist_
  build:js,jsx,ts,tsx.....[READY] (plugin) @snowpack/plugin-babel
  build:scss..............[READY] sass $FILE

▼ Console

  [log] ! updating dependencies...

⠼ snowpack installing... @css/header.scss
✖ Package "@css/header.scss" not found. Have you installed it?