-
Notifications
You must be signed in to change notification settings - Fork 886
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix TS Build Target - Compile Nullish Coalescing for broader Webpack/Babel/Node support #885
Conversation
@PaulLeCam can we merge this? |
@PaulLeCam sorry for bothering, but could it get merged? |
+1 |
Given this is taking a long time I'll point people to a version of the package I released with these changes. https://www.npmjs.com/package/@monsonjeremy/react-leaflet
Use at your own risk as I will not be further maintaining this package it is only to hold over until this PR gets merged. |
Is there any ETA for this? I tried to use the alternative package (thank you @monsonjeremy) but I am unable to do that because I have other packages depending on Alternatively, is there an easy way to redirect package dependencies without forking every package myself and modifying the imports? |
@amaster507 Can you use https://webpack.js.org/configuration/resolve/#resolvealias To force other libraries to resolve to my version? |
@monsonjeremy Thank you! I was not aware of this, figured there had to be a way somehow.
And I am up and running! I had to install your core package twice (under both the original name and alias) so that all dependencies are working. ☕ to you! |
@PaulLeCam can you please consider merging this fix!? Using the above work-arounds causes additional problems with other packages that use the wrong context file imports. See my referenced issue above this comment. @monsonjeremy Thank you so much for your help again! I at least have a working leaflet map again even if I can't use my Google layers right now. Do you have any thoughts on the above workaround with packages that are then calling the wrong context files? |
@PaulLeCam vote for merging this PR if it helps in resolving the issue. |
@monsonjeremy are you sure you even need to downgrade build target? I get the the build output without any |
@egirshov That may be true, but whatever version is released to |
True, but in case the build somehow depends on the local environment (despite of yarn.lock), I believe the proper fix would be to eliminate that hidden dependency. And in case there was a broken build/publish the solution would be simply publish new version. |
@PaulLeCam Also voting for merging this PR. We are using the react-leaflet library similarly with |
Hi huys, I tried the @monsonjeremy's version but it didn't work. Thanks you so much for replies ! |
@BowgartField This is an unrelated issue to this PR. I recommend you open an issue with that library. |
Can we please get this merged? |
Would love to have this merged! |
Is something blocking this PR ? |
One more vote for this PR. Not sure why @PaulLeCam is not willing to merge this. |
Tried to use @monsonjeremy/react-leaflet-core in combination with react-leaflet-heatmap-layer-react-leaflet-3 but I get errors extending L.Layer:`TypeError: Cannot read properties of undefined (reading 'pane') getPane(): HTMLElement {
|
As already replied in similar previous PRs, if the tools you're using don't support ES2019, that's up to you, please don't force your setup constraints on this library. |
@PaulLeCam that line of reasoning is just objectively wrong Surely you, as a library author, can see the soundness of fixing this problem at the source and not force this burden on every consumer of your library. There is a de-facto consensus in the npm ecosystem in regards to this. Actually, I made the same argument as you back in 2015 when es modules were gaining traction, but was rebutted by Rich Harris (rollup, Svelte etc) who made the exact same argument that I and other have come to realize to be true:
Please reconsider your stance. |
Was this ever fixed? This cropped up again in 4.0 and causes problems. Especially in situations where you're not in direct control of your babel transpile step. (Think large enterprise codebase and another team in another timezone on its own schedule and roadmap makes these decisions). |
bump |
Yes, it works now
Thank you
Felix
…On Mon, Aug 22, 2022 at 2:39 PM André Crabb ***@***.***> wrote:
bump
—
Reply to this email directly, view it on GitHub
<#885 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AC5AL56IZYYJA5GZQFDXS4TV2PCNPANCNFSM45FEHILQ>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Hey all, I've been looking at this the past couple days, and its still breaking. Unfortunately the browse list change didn't work for me. Any other solutions I missed that I should look at? Thanks |
Fixes: #883
This PR is meant to fix some issues that exist with the current version of the built code. Using
ES2018
as the build target will ensure that no??
syntax will make it into the build output. Unfortunately this syntax does not have broad support for packages likewebpack@4
and other bundlers. I've run into these issues running my tests in node usingjs-dom
as well.The impact should be low here (bundle size may increase a slight bit) but will make the library much easier to use for people using
next.js
andcreate-react-app
as well as people with highly custom webpack setups and those who have not made it to webpack 5 yet.