Skip to content
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

Encountered process.env when attempting to use @wordpress/block-library outside of WordPress #48949

Closed
johnhooks opened this issue Mar 9, 2023 · 8 comments
Labels
Developer Experience Ideas about improving block and theme developer experience npm Packages Related to npm packages

Comments

@johnhooks
Copy link
Contributor

Description

Why does @wordpress/block-library have a top level reference to process.env? I am trying to learn Gutenberg by playing with it outside of WordPress and using minimal build tools. Does @wordpress/script strip this out?

export const __experimentalRegisterExperimentalCoreBlocks = process.env
.IS_GUTENBERG_PLUGIN
? ( { enableFSEBlocks } = {} ) => {
const enabledExperiments = [ enableFSEBlocks ? 'fse' : null ];
getAllBlocks()
.filter( ( { metadata } ) =>
isBlockMetadataExperimental( metadata )
)
.filter(
( { metadata: { __experimental } } ) =>
__experimental === true ||
enabledExperiments.includes( __experimental )
)
.forEach( ( { init } ) => init() );
}
: undefined;

Step-by-step reproduction instructions

Use registerCoreBlocks of @wordpress/block-library in the browser without @wordpress/scripts, it will throw the following error:

Uncaught ReferenceError: process is not defined

Screenshots, screen recording, code snippet

No response

Environment info

"@wordpress/block-editor": "11.5.0",
"@wordpress/block-library": "8.5.0",
"@wordpress/components": "23.5.0",

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

@johnhooks
Copy link
Contributor Author

I was able to replace process.env.IS_GUTENBERG_PLUGIN using @rollup/plugin-replace in my vite.config.ts. Though I still think referencing process.env is strange for a published package that is intended for use in the browser.

@talldan
Copy link
Contributor

talldan commented Mar 9, 2023

I don't think those of us that worked on it realised the side effects this would have for package consumers. It's been that way for a while and it was originally thought it would be okay as there was (and still is) use of process.env.NODE_ENV across the codebase.

The IS_GUTENBERG_PLUGIN property allows Gutenberg to ship stuff to the plugin, but exclude code from WordPress core, so it has an important purpose.

It'd be good to think about how this could be fixed.

@johnhooks
Copy link
Contributor Author

I did find a solution, but if the intent is for the packages of Gutenberg to be usable outside the project a different approach for configuration would be more portable.

Any thoughts on what the state of IS_GUTENBERG_PLUGIN should be in this instance?

@talldan
Copy link
Contributor

talldan commented Mar 9, 2023

I guess one way to fix this is to ensure babel defines process.env when it builds packages.

Any thoughts on what the state of IS_GUTENBERG_PLUGIN should be in this instance?

Usually false, but it depends what you're building. In this case setting it to true would define the __experimentalRegisterExperimentalCoreBlocks export for registering some of the more experimental blocks.

The best option may be to ensure process.env is defined as an empty object, and that way IS_GUTENBERG_PLUGIN will evaluate to undefined (and be falsey).

@gziolo gziolo added npm Packages Related to npm packages Developer Experience Ideas about improving block and theme developer experience labels Mar 9, 2023
@johnhooks
Copy link
Contributor Author

@talldan thanks for the suggestion. I intent to leave this issue open. I understand I am using the library totally outside the context it was created in, but there is value in publishing the packages in a way that is easier to use outside of Gutenberg and it's build system.

@johnhooks
Copy link
Contributor Author

Decided this issue has a work around, it's documented here and people should be able to find it with a search, I'm closing it.

@gziolo
Copy link
Member

gziolo commented Apr 12, 2023

I was able to replace process.env. IS_GUTENBERG_PLUGIN using @rollup/plugin-replace in my vite.config.ts. Though I still think referencing process.env is strange for a published package that is intended for use in the browser.

In retrospect, process.env wasn’t the best choice. In webpack 4, there was a polyfill for that env variable that projects overused. This variable should get replaced with something like __IS_GUTENBERG_PLUGIN. Still, it could have to be handled by the same webpack/rollup plugin. The benefit would be it wouldn’t error when not replaced.

There is a similar issue reported in #44950.

@t-hamano
Copy link
Contributor

I also recently encountered a similar error. That's when I tried to build a block editor for my React app by following Getting Started on platform-docs.

I used Vite as a build tool, but it looks like the latest Vite has removed process.env and I needed to use import.meta.env instead.

As mentioned in the comments below, I was able to work around this by add a define in vite.config.js.

vitejs/vite#1973 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Developer Experience Ideas about improving block and theme developer experience npm Packages Related to npm packages
Projects
None yet
Development

No branches or pull requests

4 participants