You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
With #235 and rails/propshaft#181 I'm now able to successfully import all the files for the tippy.js library.
After getting all of this working, I've found that tippy.js unfortunately in its ESM bundle refers to the node property process.env to determine whether it's in a production environment. There is a closed but unresolved issue (atomiks/tippyjs#990) for that library but it seems like there has recently not been much activity over there at all.
Why bother?
Whilst there is always the suggestion of "just use a different library" I think that if we're to make this transition over to no-build as seamless as possible for rails developers, it would make sense to have optional polyfills that resolve these node-related issues.
My suggestion
I would suggest having an optional (default false) kwarg on javascript_importmap_tags called polyfill_nodeisms, resulting in something like <%= javascript_importmap_tags polyfill_nodeisms: true %>
Shouldn't we get the library maintainers to ensure that nodeisms aren't included in their esm builds?
Yes - I think a great endgame would be to have all the nodeisms removed from packages, but that is a process that could take a bit of time, and cause some friction for developers transferring.
I think that it would be great to still encourage developers to prompt their library maintainers to remove the reliance of nodeisms, so I'd suggest that our ployfills should provide "warn" logs when they're used:
For example
window.process={getenv(){console.warn("Nodeism process.env has been used; You should not rely on nodeisms to being in the browser. If process.env is being used by a 3rd party dependency, consider submitting an issue to the maintainer")return"production"}}
Request for comments
I've identified process.env as being problematic, but don't have a good sample size of libraries. So I'd be interested in hearing if there are any other problematic nodeisms that people have found getting left in their esm libraries
The text was updated successfully, but these errors were encountered:
What's the issue
With #235 and rails/propshaft#181 I'm now able to successfully import all the files for the tippy.js library.
After getting all of this working, I've found that tippy.js unfortunately in its ESM bundle refers to the node property
process.env
to determine whether it's in a production environment. There is a closed but unresolved issue (atomiks/tippyjs#990) for that library but it seems like there has recently not been much activity over there at all.Why bother?
Whilst there is always the suggestion of "just use a different library" I think that if we're to make this transition over to no-build as seamless as possible for rails developers, it would make sense to have optional polyfills that resolve these node-related issues.
My suggestion
I would suggest having an optional (default false) kwarg on
javascript_importmap_tags
calledpolyfill_nodeisms
, resulting in something like<%= javascript_importmap_tags polyfill_nodeisms: true %>
Shouldn't we get the library maintainers to ensure that nodeisms aren't included in their esm builds?
Yes - I think a great endgame would be to have all the nodeisms removed from packages, but that is a process that could take a bit of time, and cause some friction for developers transferring.
I think that it would be great to still encourage developers to prompt their library maintainers to remove the reliance of nodeisms, so I'd suggest that our ployfills should provide "warn" logs when they're used:
For example
Request for comments
I've identified process.env as being problematic, but don't have a good sample size of libraries. So I'd be interested in hearing if there are any other problematic nodeisms that people have found getting left in their esm libraries
The text was updated successfully, but these errors were encountered: