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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Parcel should auto-add process.env to posthtml-expression locals #9508

Open
yefim opened this issue Jan 27, 2024 · 2 comments
Open

Parcel should auto-add process.env to posthtml-expression locals #9508

yefim opened this issue Jan 27, 2024 · 2 comments

Comments

@yefim
Copy link

yefim commented Jan 27, 2024

馃檵 feature request

I'm trying to include an analytics script ONLY in production. I want to use a .posthtmlrc file and not a .posthtmlrc.js file to take advantage of all the caching. If parcel could inject process.env into the locals of posthtml-expression I would be very pleased :)

馃 Expected Behavior

I want to be able to use process.env in my index.html file

馃槸 Current Behavior

My current setup is:

// .posthtmlrc.js
module.exports = {
  plugins: {
    'posthtml-include': {},
    'posthtml-expressions': {
      locals: {
        NODE_ENV: process.env.NODE_ENV,
      },
    },
  },
};
<!-- index.html -->
<if condition="NODE_ENV === 'production'">
  <script src="https://cdn.usefathom.com/script.js" defer></script>
</if>

馃拋 Possible Solution

Auto-inject process.env into index.html so I can do:

<if condition="process.env.NODE_ENV === 'production'">
  <script src="https://cdn.usefathom.com/script.js" defer></script>
</if>

Maybe I should take this up with posthtml. If so, don't mind me. Thanks! Love parcel and use it extensively for new sideprojects like valentineroulette.com

@samtsai
Copy link

samtsai commented May 7, 2024

Looking for the exact same use case! For now I can only think of the config as javascript route...

@samtsai
Copy link

samtsai commented May 7, 2024

Another workaround is to create a custom posthtml plugin that can modify your dom tree. That's actually working better for me in my use case.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants