Xstate: Process references

Created on 7 Nov 2019  ·  8Comments  ·  Source: davidkpiano/xstate

Description
In packages/core/src/environment.ts and packages/xstate-fsm/src/index.ts there are references to process. Since a web browser does not have this variable, you can not load xstate using ES modules in a browser.

Expected Result
I can load xstate using ES modules in a browser.

Actual Result
process is not defined

Additional context
Same issue: https://github.com/davidkpiano/xstate/issues/227

bug

All 8 comments

As I was looking through node_modules, I noticed dist/xstate.web.js. Updating to:

import { interpret } from 'xstate/dist/xstate.web.js';

Also produced a working state. I'll leave this open for now because it's not totally clear to me if I'm supposed to be using this or if it's just for unpkg.

If this is ok, I'd consider this issue closed and #788 decline-able. I'd also like a callout in the getting started section of the docs (which I'd be happy to pr!)

Some context on why those are left in like this in both source files and regular dist files can be found:

Could I ask what's your stack, how do you utilize xstate (and other npm dependencies), are you primary a frontend or a backend developer? I'm literally very curious about this without any bad intentions. I maintain multiple fairly popular packages, many of them using this technique and in most of them, I've witnessed near-zero reports about this causing any issues. On the other hand in XState there were already multiple reports of this being some kind of a problem - so this leads me to believe that the majority of the userbase in my other projects are webpack (or other bundlers) users, most commonly with many dependencies consumed directly from npm, but some people coming to XState have different background and are getting blind-sighted by this.

To answer the original problem - that xstate/dist/xstate.web.js is supposed to be used if you want to consume this directly in the browser from CDN as an ES module. If you need similar bundle fro @xstate/fsm then please let me know and I'll prepare the build configuration for it.

Issue Resolution
If using web- notated files inside dist are the supported way, we're good. Hadn't been aware of the convention but that's really straightforward. Optionally excepting a doc callout, I'd be fine to decline the pr and close this issue.

"Could I Ask" Questions
Absolutely.

what's your stack?

Here's the exact state of the codebase I was using as of my last comment on this issue: https://github.com/ZempTime/flexible-wizard . This repo is me toying around experimenting with approaches to a new data structure we need to introduce, but when I ran into this, I realized I had the same issue here which prompted me to start writing this issue.

This was generated using open-wc and I think the info you're looking for is here.

how do you utilize xstate (and other npm dependencies)?

Almost exclusively through yarn workspaces/monorepo setups. I actively use XState wherever I can better represent my domain through XState than other means, which is to say, a lot. I use it for:

  • Complex forms
  • Signup flows
  • Sometimes just as documentation
  • Generally, I reach for it for areas "easily reasoned about as interactive pictures"

frontend or a backend developer?

At work, we're lerna/yarn workspaces monorepo with a private artifactory standing in between us and npm. We use webpack there for development (and production, of course). We're gonna be expanding to housing a lot more business logic in our node microservices soon, so it'll be used there, too. That usage will be exclusively typescript. Primarily, I'd say, frontend. Although I don't get to do anywhere near the amount of individual contribution I typically like to do these days.

Both me and @timvdlippe (from the other issues you linkd) hail from the web components world.

Personally, I also do frontend/backend work (Rails + webpacker, next/react/node, and when my arm doesn't get twisted it's node/lit-element). Here I'd say I lean much more heavily backend.

I use xstate in both places somewhat liberally.

Optionally excepting a doc callout, I'd be fine to decline the pr and close this issue.

This could be documented - sure.

Super cool to hear how XState helps you to deal with various types of problems! Great testimonial.

If you are webpack user - I'm having trouble seeing when this has actually caused you poblems. Webpack should handle those process references automatically (through DefinePlugin) - see https://webpack.js.org/configuration/mode/#usage . I'm curious how your setup differs from the default one in this regard - knowing this would give me a better picture of the reported issue.

I think I ran into this as well:

ReferenceError: process is not defined

and the line:

var IS_PRODUCTION = process.env.NODE_ENV === 'production';

My current setup (note: I'm a noob with xstate):

  • using xstate as a state machine for a video game being built in the browser with phaserjs.
  • Using Rollup as my bundler, with format: umd
  • various plugins, such as rollup-plugin-commonjs probably being the one most relevant to this discussion.

I'll use the workaround as noted above for now though.

@frehner in your case the appropriate fix for this would be using rollup-plugin-replace, like this:

import replace from '@rollup/plugin-replace';
// ...
replace({ 'process.env.NODE_ENV': JSON.stringify("production") })

You can also change "production" to "development" to get helpful error messages while developing.

Ah, good to know. Thanks.

Is there a reason that "production" is JSON.stringified?

The replacing value is put “as is” into the code - but we want it to be quoted, we want to replace with a string literal. This is just a convenience thing (that JSON.stringify), its result could be written by hand (it’s just a double quoted string)

Was this page helpful?
0 / 5 - 0 ratings

Related issues

laurentpierson picture laurentpierson  ·  3Comments

dakom picture dakom  ·  3Comments

greggman picture greggman  ·  3Comments

pke picture pke  ·  3Comments

carlbarrdahl picture carlbarrdahl  ·  3Comments