FWIW we do have a homegrown preprocessor in m-c, see documentation at https://github.com/mozilla/gecko-dev/blob/master/build/docs/preprocessor.rst - not sure if it meets your requirements, but just thought I'd put it out there. We use to preprocess JS/CSS in m-c so it'll likely be around for a while, and it can probably be updated to do new things pretty easily.
On Wed, Nov 25, 2015 at 4:43 PM, Jim Porter <jpor...@mozilla.com> wrote: > On 11/25/2015 03:18 PM, Sam Foster wrote: >> Back in the day, in the dojotookit we used a combination of feature >> detection and a require.js alike module system to build feature-specific >> sources. So rather than magic comments with preprocessor meaning, you >> got real conditionals in the code that were optimized away given a >> feature-set profile at build-time. In practice this was mostly done at a >> file/module level though - very similar to what Marcus proposes. > > How is this different from a preprocessor? Regardless of the name, > you're still adding conditionals that affect the result of a build based > on certain configuration parameters. Sure, poorly-written preprocessor > rules can result in unclear code with subtle bugs hidden within, but > we're writing *Javascript*. That ship has already sailed. > > To be clear, we're really talking about two kinds of build-time > configuration: line-based (preprocessor) and file-based (our build > system). If people have run into limitations with the latter and feel > the former would simplify their work, then I trust them on this, and my > only recommendations would be in terms of what tool to use, not whether > they should do this in the first place. > > In an ideal world, I'd prefer we just use something like the C > preprocessor, since it's one of the best-known preprocessing languages, > but as people rightly mention, this will break editors. Trying to edit > preprocessed JS/XUL files in Thunderbird has always been fairly > annoying. I'm less sympathetic to the fact that it would break our > linter, but that's probably because I think linters are a bit silly to > begin with; if you want good build-time checks that your code isn't > totally broken, you should use a compiled language and compile with > -Wall -Werror. :) > > That said, syntactically-significant comments are a bit ugly too. > However, I don't think the ugliness outstrips their value. I definitely > think we should use an existing preprocessor for this, provided we've > thoroughly analyzed its strengths/weaknesses, and are confident that we > won't end up relying on some project that gets abandoned in a year. I > don't have a strong opinion on the specific tool we use, so long as it > meets the requirements I listed above. > > Or we could use Rust's macro system. ;) > > - Jim > _______________________________________________ > dev-fxos mailing list > dev-fxos@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-fxos _______________________________________________ dev-fxos mailing list dev-fxos@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-fxos
