Rename @embroider/core/entrypoint to @embroider/virtual/compat-modules

[NullVoxPopuli]

Resolves #2025

[mansona]

I'm inclined to approve this since it does what it says on the tin and solves a serious type issue that we had. I wonder though if there could be more discussion about the approach and see if we can't do something a little smarter rather than having another package to deploy 🙈 (see my question in a comment)

[mansona]

this will literally do nothing 🤔 are these tests even run?

[NullVoxPopuli]

Better to be updated than to lie?

🤷🙈🙃

[mansona]

I mean if you delete the line no test will fail, if you delete the file no test will probably fail 🤷

there is no side-effect of importing /@embroider/virtual/compat-modules any more so just adding a script will do nothing to any app ever

[NullVoxPopuli]

should we delete the whole dummy folder?

I can't leave @embroider/core/entrypoint because it doesn't exist anymore

[NullVoxPopuli]

looks like these tests are ran https://github.com/embroider-build/embroider/actions/runs/11151185253/job/30994094350?pr=2138#step:5:293

[ef4]

I think we should do the same thing vite does for extra types (import.meta.glob, for example, needs a type declaration).

They tell you to put this in your tsconfig:

"compilerOptions": {
    "types": ["vite/client"]
  }

For us that could be:

"compilerOptions": {
    "types": ["vite/client", "@embroider/core"]
  }

And I think then we just need some declare module in core/src/index.ts.

[ef4]

Link to their docs: https://vitejs.dev/guide/features.html#client-types

[ef4]

Possibly it would be safer for us to pick a subpath like @embroider/core/client, since it's not clear that it would be good for frontend code to need to see the types for all of our build-time things.

[mansona]

@ef4 what about @embroider/core/virtual so that it makes a reference to the fact that we're typing the @embroider/virtual things?

[ef4]

I'm not sure if everything we'll ever want to put in there is under @embroider/virtual. We might want to put in import.meta.resolve for example.

[NullVoxPopuli]

As I was poking around in here , I noticed that test-support and vendor are also virtual files -- should those be under the same prefix fake-package? (maybe in a separate PR, once we work out the mechanics here?)

[mansona]

everything that is virtual should be renamed as such, and yes they should be separate PRs 👍

[NullVoxPopuli]

I think we should do the same thing vite does

this is also the same thing we do :P 🎉
(for ember-source types)

[NullVoxPopuli]

@ef4 I've updated this PR to

Possibly it would be safer for us to pick a subpath like @embroider/core/client

But used @embroider/core/virtual.

Additionally, I think I found a bug with TS where @-prefixed libraries are not resolvable from compilerOptions.types :(
So, for now, we have a /// <reference thing.

[NullVoxPopuli]

this is the only way I could get the types present when type-checking.

The (imo) nicer way, via compilerOptions.types doesn't seem to work for @-prefixed package names.