Reference error: process is not defined.

[ynejati]

Line 14 in Provider.js. If the global 'process' is not defined, it can cause the browser to throw an error. This seems like an oversight.

[danielkcz]

Definitely not an oversight, more like an issue of bundling tool - microbundle: developit/microbundle#115

[ynejati]

I would disagree. Sure, you could configure your bundler to add the global, but that shouldn't be a requirement. What if someone is using a CDN in a script tag. Are you going to require that they also add <script>process = { env : null}</script>? That doesn't makes sense.

[danielkcz]

No, I mean that microbundle is used for building this package, but fails at removing process checks. It might be more fruitful to discuss this at that linked issue.

Personally, I prefer TSDX tool which has this solved, but that would require rewriting the lib to TypeScript. Something I want to do for a long time, but still, lack the time :)

[ynejati]

I misinterpreted your response. Apologies. That makes sense, since typically this logic is/should be removed during minification/creation of the production bundle. Nonetheless, this has broken our production build, when upgrading to the latest release. Currently the work around is to ensure process.env exists in the global scope, which is less than ideal.

I've never heard of TSDX, looks interesting. Thanks for sharing.

Yes, rewriting the lib to TypeScript would take some time. It would certainly be consistent with mobx and feel more uniform, to say the least. If you think you'd like help with this, let me know.

[danielkcz]

@ynejati

Yes, rewriting the lib to TypeScript would take some time. It would certainly be consistent with mobx and feel more uniform, to say the least. If you think you'd like help with this, let me know.

I don't think it would be too difficult. Since V6, the package is fairly trimmed down with most of the core logic in mobx-react-lite and general simplification with Hooks. If you are feeling for it, PR is definitely most welcome.

Nonetheless, this has broken our production build, when upgrading to the latest release.

That's strange considering that line of code was there more or less half a year. I guess you can stay on the older version for now till this is properly figured out.

[mweststrate]

typically a `typeof process !== 'undefined'` as prefix for the condition fixes this.

…

On Fri, Nov 15, 2019 at 4:32 PM Daniel K. ***@***.***> wrote: @ynejati <https://github.com/ynejati> Yes, rewriting the lib to TypeScript would take some time. It would certainly be consistent with mobx and feel more uniform, to say the least. If you think you'd like help with this, let me know. I don't think it would be too difficult. Since V6, the package is fairly trimmed down with most of the core logic in mobx-react-lite and general simplification with Hooks. If you are feeling for it, PR is definitely most welcome. Nonetheless, this has broken our production build, when upgrading to the latest release. That's strange considering that line of code was there more or less half a year. I guess you can stay on the older version for now till this is properly figured out. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#801?email_source=notifications&email_token=AAN4NBD2TTOND7P6RALZUCTQT3FINA5CNFSM4JNQWBIKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEEF7KDA#issuecomment-554431756>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAN4NBE6UVSHYC22CGJJWE3QT3FINANCNFSM4JNQWBIA> .

[mweststrate]

Most bundlers substitute it automatically, which is why it is barely reported, but I think we should fix this on our side. On Fri, Nov 15, 2019 at 4:56 PM Michel Weststrate <[email protected]> wrote:

…

typically a `typeof process !== 'undefined'` as prefix for the condition fixes this. On Fri, Nov 15, 2019 at 4:32 PM Daniel K. ***@***.***> wrote: > @ynejati <https://github.com/ynejati> > > Yes, rewriting the lib to TypeScript would take some time. It would > certainly be consistent with mobx and feel more uniform, to say the > least. If you think you'd like help with this, let me know. > > I don't think it would be too difficult. Since V6, the package is fairly > trimmed down with most of the core logic in mobx-react-lite and general > simplification with Hooks. If you are feeling for it, PR is definitely most > welcome. > > Nonetheless, this has broken our production build, when upgrading to the > latest release. > > That's strange considering that line of code was there more or less half > a year. I guess you can stay on the older version for now till this is > properly figured out. > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > <#801?email_source=notifications&email_token=AAN4NBD2TTOND7P6RALZUCTQT3FINA5CNFSM4JNQWBIKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEEF7KDA#issuecomment-554431756>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAN4NBE6UVSHYC22CGJJWE3QT3FINANCNFSM4JNQWBIA> > . >

[ynejati]

Seems that mobx-react-typescript-boilerplate's mobx-react.module.js file looks like this, properly bundling and aliasing to true because it actually runs through webpack:

For us, we use mobx-react as an external, grabbing the "production bundle" from node_modules and injecting into a script tag. We did the same before upgrading from 5 to 6. Ideally we would use Webpack's expose-loader, to do this, but the plugin appears to be broken for webpack 4. As a result, since mobx-react.module.js still contains process.env it breaks our build.

[ynejati]

Yes, I agree. It would be nice to add a simple check like process && process.env similar to the mobx minified build. Might have to do this for mobx-react-lite as well.

[danielkcz]

Well, the mobx-react.module.js should definitely stay as close as possible to the original code. ESM format is something that bundlers need to handle and it shouldn't be used out of the bundling system. Had the annoying issue in the past which basically lead to TSDX leaving ESM format as is. The CJS and UMD formats are surely a different story.

@mweststrate

typically a typeof process !== 'undefined' as prefix for the condition fixes this.

I would argue this is a scalable solution. How annoying would that be with several dev-only checks in the code? I know it does not apply to this case but feels like starting some weird trend instead of fixing the issue at its root 🤷‍♂

What I also love about TSDX that it will expose __DEV__ global variable and then you don't need to worry about the lengthy check and it will be correctly transformed. Not sure why microbundle is so badly lacking behind.

[mweststrate]

I have to yet checkout TSDX Yousuf make sure to pick the UMD build! not the .module.js build, that is _not_ intended for direct use in the browser and might have many issues beyond just process not being available.

…

On Fri, Nov 15, 2019 at 5:56 PM Daniel K. ***@***.***> wrote: Well, the mobx-react.module.js should definitely stay as close as possible to the original code. ESM format is something that bundlers need to handle and it shouldn't be used out of the bundling system. Had the annoying issue <jaredpalmer/tsdx#140> in the past which basically lead to TSDX leaving ESM format as is. The CJS and UMD formats are surely a different story. @mweststrate <https://github.com/mweststrate> typically a typeof process !== 'undefined' as prefix for the condition fixes this. I would argue this is a scalable solution. How annoying would that be with several dev-only checks in the code? I know it does not apply to this case but feels like starting some weird trend 🤷‍♂ What I also love about TSDX that it will expose *DEV* global variable and then you don't need to worry about the lengthy check and it will be correctly transformed. Not sure why microbundle is so badly lacking behind. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#801?email_source=notifications&email_token=AAN4NBGKSZ7JJ6CAPTIUVXLQT3PERA5CNFSM4JNQWBIKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEEGHA3Q#issuecomment-554463342>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAN4NBHLPGFJZZMTUIQE3RTQT3PERANCNFSM4JNQWBIA> .

[ynejati]

@mweststrate Thanks for the heads up. We are actually using the UMD build already, but good to know.

@FredyC You sure are pushing TSDX pretty hard. I'm beginning to think that they are paying you. ;)

[ynejati]

In mobx's entry point, mobx.ts, we conveniently have:

try {
    // define process.env if needed
    // if this is not a production build in the first place
    // (in which case the expression below would be substituted with 'production')
    process.env.NODE_ENV
} catch (e) {
    const g = getGlobal()
    if (typeof process === "undefined") g.process = {}
    g.process.env = {}
}

Should we do the same here?

Curious though, why mobx being a peer dependency and supposedly loaded first on the page didn't prevent my problem?

[mweststrate]

Released in 6.1.5

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs or questions.