statelyai / xstate

Actor-based state management & orchestration for complex app logic.
https://stately.ai/docs
MIT License
27.18k stars 1.26k forks source link

Process references #787

Closed ZempTime closed 1 year ago

ZempTime commented 5 years ago

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

ZempTime commented 5 years ago

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!)

Andarist commented 5 years ago

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.

ZempTime commented 5 years ago

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:

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.

Andarist commented 5 years ago

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.

frehner commented 5 years ago

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):

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

Andarist commented 5 years ago

@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.

frehner commented 5 years ago

Ah, good to know. Thanks.

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

Andarist commented 5 years ago

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)

davidkpiano commented 1 year ago

Fixed in v5 beta in #4016