Support custom directory for installed dependencies #441
Comments
FredKSchott
added
contributors welcome!
FredKSchott
changed the title
|
Hey @FredKSchott happy to take this one if you want. Does configuring this through a new top-level config option like Should this also respect the Snowpack is 👍 I'd be more than happy to contribute! |
|
Hey Dan, that sounds great! I can give a quick overview of what's needed:
That should cover everything, but feel free to reach out with any questions. |
|
As for the config itself, I'd try to keep the |
|
@FredKSchott Somewhat related to this I was trying to get The latter wasn't working since the entrypoint JS module was trying to import React from Anyway, I solved it with some clever Electron magic, but I'm wondering if something related to this might be helpful there? Two more things, 1) I love Snowpack! ❤️ and 2) would a create-snowpack-app template for Electron be helpful, or is that sort of out of scope? Would be happy it contribute if you like the idea. (Oh and sorry for semi-hijacking this issue! 🙈 ) |
|
If you found Snowpack to be a good fit for Electron, I think that could be a great community template to add to the README! I think it would be out of scope for our team to maintain for now It would also be great to add an "Electron" recipe/guide to our main docs site, with a link to https://gist.github.com/hamstu/b1f88ea486508111668df8d39e2d0ca1 for future users. To your specific issue, I don't this solves it, since this is just customizing the final path (but it would still exist at |
|
If I remove the If importing from How does that work with packages that have a Is there an example of the best way to read args from the normalized scripts? I can see the Final question (I promise!). What's the best way write an integration test that tests the import rewriting? I can't see any existing tests that do that, but I haven't dived too deep into |
|
All great questions!
|
|
Ok, so I've been getting stuck into the build command this evening. It's been slow going but I've got a new round of questions. The default Here's an example of the script I've been using to try and mount the "mount:test": "mount $WEB_MODULES --to /static/web_modules"When the "mount" scripts are parsed there doesn't seem to be anything that evaluates the variables, so When the build script eventually tries to run that mount script, nothing is copied to I can't actually see where that |
|
lol, I just realized that You'll want to do something like this in config.ts: // ...
if (scriptType === 'mount') {
// ...
if (scriptId === 'mount:web_modules') {
+ dirDisk = process.env.NODE_ENV === 'production' ? BUILD_DEPENDENCIES_DIR : DEV_DEPENDENCIES_DIR;
}
}
processedScripts.push(newScriptConfig); |
|
Longer term I think I'd prefer to handle the web_modules location with an option that wasn't a mount script. It doesn't really feel comparable to other mount scripts because it's an opaque directory that lives outside your project on disk (as opposed to your That means that we're always going to be quietly ignoring whatever you pass as the first argument in the script. "mount:web_modules": "mount i_will_be_ignored --to /web_modules_2"What about controlling it through a
|
|
Yea, I'm more and more convinced that that's a good direction to go, maybe even for all mount configuration logic (we already went that direction with I'll spin up an issue to discuss a new design seperately. Thanks for tackling this!!! |
|
@hamstu Could you share the electron example that you have created? I can't seem to be able to figure out the relative paths with |
|
@FredKSchott I also would like to use snowpack with electron. However, I am not sure how to use in my setup which has both web and electron frontends which largely share identical code. Currently, I "rollup" two bundles for the part of the code that depend on node built-ins, using polyfills for the web versions. I wonder if there is a way to:
|
|
That's interesting. You could use |
|
You should be able to do that by using '@rollup/plugin-node-resolve' using the 'preferBuiltins' option. But snowpack complains with, say, But even with the above resolved i.e. if am to exclude node-builtins, I will only be able to use it with electron (and not in the browser). My dual use purpose is not achieved. I realize this is not an intended use case for snowpack, but it seems like a natural extension - in this case, I am trying to avoid running two builds (instead of the usual one), every time I make changes to my code. |
|
Yup, that makes sense. It out of scope to support both today. I'd actually love to see an example of something that uses Node builtins today (no polyfills) that runs in both the browser and electron, since I'm not sure how that would work. Unless you mean to only polyfill on the web and not polyfill in electron, but by definition that would ned to be two builds regardless. |
|
Hi All, I am trying to upgrade the snowpack version from 2.6.4 to 3.8.7. I want to upgrade my snowpack version to 3.8.7 but I am not able to configure the install directory and I have done following changes: } |
Original Discussion: https://www.pika.dev/npm/snowpack/discuss/308
/cc @jhfbosman, @FredKSchott
Right now, we hardcode that your dependencies live at "/web_modules/" in your deployed application. This was mainly out of convenience for our path rewriting logic, and not any real technical limitation.
A user should be able to customize where their web_modules directory is mounted to, and our dev/build workflows should support this. I believe this will only require a few fixes in our "import rewriting" step to support.
Note: Make sure that #448 is tackled as a part of this
The text was updated successfully, but these errors were encountered: