-
Notifications
You must be signed in to change notification settings - Fork 3.2k
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
move 3rd party types to dev dependencies in CLI NPM package #3425
Conversation
@tgriesser can you take a look at the typescript changes - read the issue for motivation, trying to prevent type clashes between our bundled types and users' (like Lodash) @NicholasBoll if you can take a quick look, we would appreciate it. Chai and jQuery are weird types since they are global and I had to delete |
This makes sense that we'd want to avoid including types that would conflict with users' installed types. I'm wondering if there's any tooling that exists already that will solve this problem more generally for us, by effectively bundling them inline when they're imported so we have one (or two) big d.ts files which handles the namespacing, etc. https://github.com/timocov/dts-bundle-generator I might play around with this because I've been wanting to solve this problem for knex as well, as it currently has But generally I think the approach here makes sense, without getting it running i'm not sure if there's any issues with it. |
@tgriesser I have looked at the TS bundle generators, they would need to tested well, since all require extensive configuration, and I have never used them. For now I think copying dependencies would do, and I will open a separate issue to find and use TS bundler. |
At first I thought this was a terrible idea, but now I like it. The problem is around global definitions (namespaces) that collide. I looked into jQuery type definitions and chai type definitions. It looks like jQuery breaks up namespacing into different files, but chai looks like its namespace is in the same file. Does deleting it cause type errors where the chai type is not found? Do you want me to try out these changes to verify it will work externally? |
ughh, typescript@next does not like this change at all
and so on in https://circleci.com/gh/cypress-io/cypress/75061 |
Testing build NPM package
against kitchensink still has a problem
|
I think the TS problems have been solved, all 3rd party deps use relative paths, tested against types in Kitchensink and TodoMVC, both are happy with new types |
@@ -754,6 +763,7 @@ linux-workflow: &linux-workflow | |||
branches: | |||
only: | |||
- develop | |||
- move-ts-types-to-dev-dependencies-3371 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be deleted
Is this supposed to solve cypress installed I also saw post-install.js which seemed like it would take care of it, but |
…io#3425) * wip: move lodash types to dev dependencies * move blob-util types * move types for minimatch * do not lint types from minimatch * move types sinon to dev dependencies * move sinon-chai types to dev dependencies * update tslint * move types bluebird to dev dependencies * move mocha types * move jquery types to dev dependencies * rename moment local wrapper * move chai and chai-jquery * refactor code for building CLI and dealing with folders * linting * include types subfolders * replace types with relative paths * transform sinon path to relative * linting * do not delete d.ts files * linting * chore: build npm package from this branch * add minimatch relative reference * work around minimatch * set sinon to be relative load * add readme to CLI * linting readme
@types/lodash
@types/blob-util
@types/bluebird
@types/minimatch
@types/jquery
@types/chai
@types/chai-jquery
@types/mocha
@types/sinon
@types/sinon-chai