Fix: sources should properly require dependencies for Node compatibility #3
Conversation
Creating this largely as a discussion topic (since issues aren't open). Can dependencies please be handled properly such that using this from `nodejs` "just works" - like with every NPM libraries - ie, libraries (in raw form) should require their own dependencies... Users should not be forced to rely on globals just to use the library from Node proper. I do think the final distributable would be improved if it also bundled `colorparsley` (a tiny dependency) rather than forcing client-side users to deal with dependency hell, but that's a secondary issue. --- Also: Can the fact that this is a template repo be fixed and could issues be opposed to allow people to file issues?
joshgoebel
changed the title
joshgoebel
changed the title
|
Hi Josh @joshgoebel Thank you! Just FYI, discussions are open at the MAIN repository, which is https://github.com/Myndex/SAPC-APCA/discussions And the more complete documentation is in https://github.com/Myndex/SAPC-APCA/tree/master/documentation I suppose I should make that more clear!
LOL. This project, and the related colorparsley, are the first projects I've published on npm. As it started as a client side script, it may not have everything in pace for node.js, though I am working to make that a smoother experience. I was under the impression if I listed the dependency in the package.json that it would be included, though I see my import statement was commented out at compile time, and I see that you've suggested using the require sttement instead. Do I need to change the extension from .js to .cjs? I think this is partly due to how I have my dev environment setup for GitHub desktop and npm. I am happy to entertain suggestions to help improve compatibility—mainly to shift my dev environment from client-side oriented to node. Any resources you might suggest? Thank you for your help! Andy |
Welcome. :-)
No, that just gets it installed... you still need to require/import it when it's needed. (for Node.js)
Well, it's kind of a mess right now unless you embrace ESM everywhere... (making it harder for some to use your library IMHO). You might read: sindresorhus/meta#15 or google ESM vs CJS Right now Highlight.js publishes:
So we turn one code base into 3 different use cases/builds for people:
Our core library is all clean ESM code that's compiled to whatever module type is needed. However our build tools/scripts are current still all CJS... so if you went ESM only that would mean we couldn't use your library. For Summer 2022 we're considering going ESM only and dropping our CJS Node build (but not the browser monoliths). Sorry I'm not more help. |
|
If your library is mostly self-contained (as it seems to be) I'd recommend publishing a browser-ready JS file that is "all batteries included" (meaning it compiles in the |
Personally I still think issues should be open here (for issues related to the npm library/source specifically not the larger project), but that's just my opinion - and what I think is most common... some people/large projects have different ideas on these things. :) |
|
Hey @joshgoebel thank you for the additional thoughts and resources. Because of the overall goal and the nature of the project as a emerging international standard, I want to make apca-w3 and Bridge-PCA as easy to implement and compatible as possible, so thank you for the tip on using rollup... And yes, apca-w3 is now self-contained, with the only dependency being colorparsley which is used by the entire rest of the family. I opened the discussions tab instead of issues as it seems to be the only way to pin a thread that indicates the main repo is elsewhere, and what should be there vs here. Thank you! |
|
Hi @joshgoebel I just started a branch called BuildTools and am integrating the work Alex did, updating to the new functions of course, hope to have these published this week. |
Creating this largely as a discussion topic (since issues aren't open). Can dependencies please be handled properly such that using this from
nodejs"just works" - like with every NPM libraries - ie, libraries (in pre-bundled form) should require their own dependencies... Users should not be forced to rely on globals just to use the library from Node proper.I do think the final distributable would be improved if it also bundled
colorparsley(a tiny dependency) rather than forcing client-side users to deal with dependency hell, but that's a secondary issue.Also: Can the fact that this is a template repo be fixed and could issues be opposed to allow people to file issues?