Tagged template literals and wizardry

[jorgebucaran]

Here is a totally crazy idea. I am posting it here because I don't have time to work on it right now.

If this is just too crazy for fly, I can accept it (I can already see it might be too crazy indeed). A new module would do just fine in that case.

const source = ["src/**/*.js", "!src/ignore/**/*.js"]
const target = ["dist/app.js"]

module.exports = `
    watch ${source} >
        eslint {no-extra-semi: 0}
        babel {es2015, state-0}
    > concat > target > ${target}
`

[lukeed]

Screams "decorator" 😆 Easily doable as a decorator.

(Let's keep labels & milestones clean.)

[jorgebucaran]

Maybe? I don't think so. This is just another build DSL.

Template literals open the door to all sort of magic. Sure, too much magic can be dangerous, but this is an idea that might work out for another build system then.

I use dev servers more than build systems these days, but something like this could bring back the fun in writing build files for me. Imagine all the sort of cleverness that would go into making the above work!

Again, I am just toying with ideas. This has nothing to do with #241, so no worries.

[lukeed]

Haha, I still see it as a decorator. Although it is cool, it's extra magic that doesn't need to be run in core.

It's either a new build tool, as you say, or a fly decorator. Our API and usage has been well-used and well-tested. Everyone is quite happy with it and its simplicity.

[jorgebucaran]

@lukeed For a build system based in that thing above that was also compatible with fly, I would parse the template and generate an object that fly can execute.

[lukeed]

Exactly. That's what makes it a decorator!

[jorgebucaran]

When does it stop being a decorator and becomes its own language? Or is JavaScript a decorator of C++?

[lukeed]

Lol you can call it an abstraction if it makes you feel more comfortable that way.

But right now, as you have it, it still uses template literals, injecting source and using api methods. You can regex this down and perform some behind the scenes magic so that Fly gets what it wants, and that's what defines an abstraction/decorator pattern.

It's up to you and how far you want to take this syntax. Obviously, at some point, it becomes its own thing (or more like a Make clone). You'll have to decide if it still should compile down to fly-compatible exports, or becomes its own runner.

Worth exploring if you're interested.