Closes #94 Closes #44

Benefits

• closer to other tools in the svelte ecosystem
• Faster bundling (~33% speed improvement locally from 3s to 2s)
• Smaller bundle (not tested, but dropping babel should dramatically decrease the bundle size)
• more consistent formatting
• we are in full control of the printing, as we own esrap

Downsides

• Potentially to consistent formatting, as it looks like it's completely ignore the user input (tabs vs spaces, etc), but that's probably fixable in esrap
• Custom typing for special typescript types (see packages/ast-tooling/ts-estree.ts) and Rich-Harris/esrap#13 for reasoning and considered alternatives.

Depends on Rich-Harris/esrap#13. Currently published as esrap-typescript-temp for ease of use for testing. Otherwise, this would require using pnpm link locally with the branch mentioned before.

If we want to proceed with this (which i think we should), this needs to be done

• publish packages/ast-tooling/ts-estree.ts seperately so that it can also be used inside esrap. Later they should probably live inside acorn-typescript once we fork it
• make esrap understand what a TSModuleDeclaration is and how to print it
• update types inside esrap according to the types above. This will probably also require way more types in this new package
• merge the pr inside esrap and publish it
• fix todos
• Testing. I have done a few tests here and there and generally the formatting is way more consistent and matches what i would expect.

Closes #44 Closes #118 Relates #100

This basically duplicates #100 at this point. See #100 for up and downsides of this approach.

I was initially intending to get rid of a lot more dependencies (like the dependencies for handling html) and use svelte-ast-print instead, but this was opening too many issues at the same time. That's why I opted to "only" switch to acorn and esrap here, the rest can be done later.

Relevant PR's / issues

• Rich-Harris/esrap#18
• Rich-Harris/esrap#19
• sveltejs/esrap#44
• sveltejs/esrap#47
• sveltejs/esrap#51
• sveltejs/esrap#45
• sveltejs/esrap#52

Benefits

• closer to other tools in the svelte ecosystem
• Faster bundling (~33% speed improvement locally from 4s to 3s, probably more with #371)
• Smaller bundle (locally 2.6MB vs 3.6MB)
• more consistent formatting than the strange things we sometimes experienced with recast
• we are in full control of the printing, as we can control esrap

Downsides

• Our custom typing for TSEstree as no good public alternative exists, that matches acorns output. We do have @typescript-eslint/types but that was just the one with the smallest pain points. Still exploring other options.

Closes #94 Closes svelte-add/svelte-add#193 Closes svelte-add/svelte-add#507

This is a pretty rough poc to try and make sv work better with .svelte files. Under the hood, this uses svelte-ast-print

Step 1 (support for svelte files):

• support for svelte specifc html syntax (@attach, self closing component tags, transitions, etc)
• check and adapt all other usages of parseSvelte
• make svelte-ast-print support indentation and quote styles (I think some of that already works)
• fix formatting mistakes in svelte-ast-print (first write up: xeho91/js-ast#128)

Step 2 (reduce deps, different pr probably)

• we currently use many different libraries for parsing and serializing JS / CSS / HTML. All of that could in theory be handled by svelte/compiler and svelte-ast-print. Check which hoops we need to jump to make that happen. We could potentially drop the following deps:
  • dom-serializer
  • domhandler
  • domutils
  • htmlparser2
  • postcss