Environment options? (Globals and safety)

[mindplay-dk]

I'm looking to try Hegel on a project where browser requirements are extremely important.

That is, this projects targets a very specific set of browsers, and browser features.

I noticed the environment configuration setting, which lets you switch between nodejs and browser - it leaves me wondering, what's implied by browser exactly?

I guess I was expecting more options, along the lines of Typescript's --lib option, which lets you target different browser standards and feature proposals and so on. Where does Hegel get it's type-definitions for browser globals?

It's critical to the management of this project that any dependency on browser globals be completely explicit, centrally managed, and fully opt-in. For example, if we've decided not to use Promise, it's critical that someone can't jump in on this project and accidentally introduce a dependency on Promise just, say, out of habit. The build should fail.

I do plan to use ponyfills for this project, almost exclusively - so maybe the best approach is to use Hegel with no environment? Which seems to be the default. I would then explicitly export every browser global (or ponyfills) from modules, and import these everywhere else, avoiding all global references.

But let's say, for example, I put fetch or a ponyfill behind a module - then where do I get the type of window.fetch from?

Thanks :-)

[thecotne]

you can grab types from here https://github.com/JSMonk/hegel/tree/master/packages/typings
or you can use any .d.ts file in hegel (some features of typescript are absent in hegel so you may need to tweak .d.ts files)

[mindplay-dk]

Okay, so the built-in typings were based on the TS typings, hmm... kind of makes me wish they had those available as a package rather than bundled with the language.

Do you maintain this file by hand? and which TS --lib files is it based on then, all of them?

Why is most of that file commented-out?

(There's an opportunity to do better than TS here, I think. Maybe the typings could actually be installable packages with version numbers, so we could have modularity like --lib in TS, but without the breaking changes that sometimes get sprung on you when you upgrade to a newer version of TS - I've been hit by that more than once. The "environment" option gets the project off the ground, I guess, but it seems like a bit of an oversimplification... browser environments/targets are, ehm, colorful.)