[Discuss] It's time to clean up config! Post things you found confusing here!

[FredKSchott]

Plenty of config overlap & incorrect organization has popped up over the last few months as we've grown. Let's get a full list together of things that we can clean up in our config.

My personal improvement wish list:

• include & extends - Right now, we scan all files in your project by default. This was meant to solve the "zero-config" use-case in simple projects, but some people are confused by this behavior, especially in apps with other file types (ex: Java web app). We should either make this behavior more clear on first run, or scrap it entirely.
• Any concept of "public" or "vendor"? Plenty of projects have a directory that includes vendor'd files that aren't meant to be built. We should have a way to set directories as "part of the final app" but "don't build/scan these files for deps".
• devOptions.out -> buildOptions.out
  • Lesson for any open source maintainers out there: Don't over-index on organizing your configuration until after the project has had a chance to grow a bit.
• devOptions.fallback -> ??? We need something better to signify that you're in SPA mode, and when to serve a 404 for unmatched routes. Right now, we assume that you're always in SPA mode.
• https://github.com/pikapkg/snowpack/pull/854/files#r473867640 installOptions.env creates a footgun for unintentionally including sensitive process.env variables.
• Anything else??? Kvetch away!

[Akiyamka]

Yep, I have proposal about include
#858
And I think we need ability to rewrite hardcoded folders in exclude options

[FredKSchott]

Thanks for proposing! Definitely +1 on cleaning this up

[stramel]

I also brought up similar things in this discussion: #617

• out appears in the devOptions but appears to only be utilized for build (Docs: Fix out config option #582)
• bundle appears in the devOptions but appears to only be utilized for build (Docs: Fix out config option #582, Should the bundle dev option be a build option? #589, Pika 486, Pika 485)
• treeshake appears in the installOptions (Pika 485, Should the bundle dev option be a build option? #589)

[FredKSchott]

Ah, I knew I remembered you posting something similar. +1 for all of these!

[silverwind]

One minor suggestion related to config docs:

I'd suggest to include the config object key, e.g. installOptions.dest instead of just dest. When reading these docs for the first time, I had to constantly scroll up to the JSON example to find the top-level key for a specific option.

[FredKSchott]

+1, this is a good idea. I'd accept a PR for this anytime, separate from the larger clean up work

[MoonBall]

what is the difference about buildOptions.webModulesUrl and installOptions.dest?

[FredKSchott]

oh this is a good one!

• installOptions.dest: when you run snowpack install, what local directory are your dependencies installed to
• buildOptions.webModulesUrl: when you run snowpack build (or dev) what URL should your dependencies be hosted at / imported from?

How we document our entire install command should really be revisited for a v3 release, there are tons of concepts like this that now overlap with build/dev options.

[MoonBall]

I find that installOptions.dest option isn't be used.
The output directory is node_modules/.cache/snowpack/dev in dev mode and
it's path.join(buildDirectoryLoc, config.buildOptions.webModulesUrl) in build mode.

[FredKSchott]

Yup, we have an old snowpack install command that uses this, but that command is no longer used much.

[FredKSchott]

Bump for v3. We've actually tackled a lot of these already in v2.0!