How, exactly, do modules work in parcel (v2)? #5377
-
|
I started using parcel as a way to manage the dependencies of my frontend using a proper package manager (npm, in my case), instead of just downloading zip files and placing them in my frontend's source root as I used to do. After doing so, I found some other features (mainly minification and compile-time error detection) to be quite useful, but something is still a constant source of problems: modules. Most of my background is in systems programming, more traditional non-election desktop development, and game development, so I know C++, Rust, and Java very well, but I only know the very basics of JS: I read most of a 90s book on JS years ago to get the basic syntax, and then I use a search engine constant whenever I do anything that I'm not sure about. This works well enough to get something that at least works, except when I need to deal with parcel's modules. I constantly get module errors in my system, and it's woefully unclear to me what's going on even when it works. For example to get Bootstrap's CSS into my exported frontend I need to do JS code — but CSS is specified by a
This tells me that if I go and learn standard ES6 module syntax (my understanding of what "ES6" means is that it's just the standard dialect of the latest version of JS), then I can use that in Parcel without problem — there are no asterisks or other caveats listed here, so I expect it to work exactly how ES6 modules work normally. It's either that or it's lying by omission. As such, I read this page, which I thought would give me the full story, but what I learned then contradicts what happens with parcel. Firstly, that page describes modules as an opt-in feature: regular JS files still exist. Yet, in Parcel, it seems that every script is somehow a module because I need mysterious As such, I ask: what can I read to get a comprehensive and completely correct understanding of how this works? Once I finish reading it I should be able to predict with absolute certainty and without any assumptions how parcel will behave with any given module code (perhaps not down to the exact error message), and know the good practices for writing my own code. Anything with less detail is sure to simply produce an incredibly frustrating experience as I randomly try to guess what's going on in the absence of good documentation. If good documentation doesn't exist, then how can I learn what I seek to learn? A huge number of people do successful web development every day, so surely it's possible. Lastly, while this may seem a bit ranty, that isn't the intention. I genuinely want to know how to do this, but it's been a very frustrating experience so far due to the lack of comprehensive documentation, and that frustration may have shown through. There's only so far that inference upon inference from incomplete and contradictory documentation can go. |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 1 reply
-
|
I replied on your other issue as well, but wanted to help explain a couple thing you saw here as well. I explained the need for assigning to the global scope manually there. Your other attempt at using ES module syntax, was a simple mistake with a possibly confusing error. As for documentation, it's always ripe for improvement. The v2 docs site (https://v2.parceljs.org) has somewhat more detail, but it's still a work in progress. |
Beta Was this translation helpful? Give feedback.
-
Thank you very much! This clears up a lot, and I can use Parcel now :) I do have one follow-up question though: I tried to find this information on v2.parceljs.org, but I was unable to do so. Would you be able to give a specific link to where "somewhat more detail" is? |
Beta Was this translation helpful? Give feedback.
I replied on your other issue as well, but wanted to help explain a couple thing you saw here as well. I explained the need for assigning to the global scope manually there.
Your other attempt at using ES module syntax, was a simple mistake with a possibly confusing error.
export function myFunctionexports a function calledmyFunction, butimport myFunction from "./assets/myfunction.js"imports the default import from that module. Either the named import syntaximport {myFunction} from "./assets/myfunction.js" or the default export syntaxexport default function myFunction` would have worked, they just weren't matching up quite right.As for documentation, it's always ripe for improvemen…