Closed ZempTime closed 1 year 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!)
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:
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):
format: umd
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)
Fixed in v5 beta in #4016
Description In
packages/core/src/environment.ts
andpackages/xstate-fsm/src/index.ts
there are references toprocess
. 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