Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Publish non-global version of definitions #215

Open
wolfgang42 opened this issue Sep 4, 2022 · 3 comments
Open

Publish non-global version of definitions #215

wolfgang42 opened this issue Sep 4, 2022 · 3 comments

Comments

@wolfgang42
Copy link

I have occasion to use some of the Screeps type definitions outside of the Screeps environment. (I'm making a server-side implementation of RoomVisual for visualizing test results and want to make sure the interfaces match.) However, installing @types/screeps imports all of the definitions everywhere in my project, which is a recipe for confusion when most of the objects aren't available in my environment. From what I understand of DefinitelyTyped/DefinitelyTyped#5045 (comment), it sounds like the way to make this work is to have two packages, one to declare everything and the other to export it all into the global namespace.

I've proved this to work conceptually in wolfgang42@45c0ee2, but that was done by hacking up the build scripts and TBH I'm not really sure of the correct way to structure this. So I'm opening this issue to start the discussion; further thoughts are appreciated.

@pyrodogg
Copy link
Member

pyrodogg commented Sep 7, 2022

This project is primarily intended for players to use in the game. In that context, there are some assumptions built in. Like the game providing everything in global without having to import it from any particular module.

At the same time, your use case for typing out-of-game tools also sounds useful. And I can see the limitations about not being able to "put the genie back into the bottle" with oversharing in global.

This might need a bit of thinking about. From glancing at the linked thread, it's difficult to draw conclusions from 2016 PRs that don't resolve in merges, and vague references to "best practices". I don't see a @types/lodash-module OR an @types/lodash-global option and npm install @types/lodash still types _ as LodashStatic into the global namespace, instantiated or not.

Granted, assuming _ is lodash is far less global pollution than this package is making, but it's the same functionality.

Explicitly packaging a second module package seems like a possible solution but also as a rather large hammer. Will need to do a bit more research and testing.

@wolfgang42
Copy link
Author

Yeah, definitely a bit of an unusual use case that I've got, and I agree that the issue I linked isn't especially helpful. I'll do some more investigating and let you know if I come up with anything.

@Jomik
Copy link
Contributor

Jomik commented Oct 5, 2023

If you install typed-screeps, then it wont be in typeRoots by default, so you would have to explicitly import the types using import 'typed-screeps', maybe that works?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants