[beta] template-tag code mod

[void-mAlex]

still WIP but sharing for progress tracking/early feedback
compatBuild alternative for running an app code through embroider… to get gjs/gts files

//ember-cli-build.js

const { templateTagCodemod } = require('@embroider/compat');

-return compatBuild(app, Webpack, opts);
+return templateTagCodemod(app, {shouldTransformPath: (component_path) => true, dryRun: false});

builds upon base branch to get correct importable paths for 'builtIn' helpers/modifiers/components

[ef4]

Generally has the right shape.

It would be good not to need to know about the structure of #embroider_compat/ imports. Ideally all imports would be passed to the resolver to decide what to do with and based on the output path discovered the codemod would decide to inline that result or leave it unresolved.

[mansona]

I know this is still draft but we tried it on a reasonably large app and came up with a few problems 🙈 I'll list them here but please ignore if you're not in the mode for feedback 👍

• there are a few places where you're using __dirname to find the embroider build but it should be using process.cwd()
• this whole system seems to break if you have a babel config file (i.e. for a vite run) so we need to figure out the babel config setup for running files
• if you have a basic babel config file with just a typescript plugin this process fails because it needs to parse your app using your app's babel config e.g. ember-concurrency transform. We probably need to use the same process that embroider uses to load the config
• we're missing an export from @embroider/compat
• babel-plugin-ember-template-comilation is being looked for relative to the app rather than relative to @embroider/compat so we probably need to find it using require.resolve before passing it to babel

[mansona]

this brings me back to what I said during the call. I imagine having a remove function that verifies that the file is in the repo (maybe after following links) before it tries to delete anything would be good enough for most people 🤔

[void-mAlex]

anything can happen between the time the function verifies that, and actual actioning of the remove opration, git rm handles all of that very nicely for us which is perfectly.

even if we had a function to test it's within the repo, what the current implementation does is not remove anything that isn't backed up (read source controlled) which is WAY safer than removing things that happen to be in the repo. and only creates things that don't already exist.

I always error on the side of safer when it comes to removing things on behalf of users and in this case it's the test that can't cope with the solution, so we shouldn't implement a lesser solution so the test is happier

[mansona]

how about inverting it? make it have an optional config that you can pass a remove function to and we can add it to the docs that if you want it to do a git remove for reasons then you just pass a function that does git remove

thoughts?

[void-mAlex]

configuration is to be avoided if possible.
convention is that code mod does the right thing by default

if anything we need to make scenario tester source control aware/capable

[mansona]

on a personal note I'm very excited to see this 😍