-
-
Notifications
You must be signed in to change notification settings - Fork 4.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
[FEATURE beta] Introduce preview types #20193
Commits on Sep 13, 2022
-
[FEATURE] Introduce a preview types package
Copy the types from DefinitelyTyped, and set up a bare minimum config to make it possible to iterate on them. This particular commit fails all type checking and has an enormous amount of work to do, but provides a foundation on which we can iterate.
Configuration menu - View commit details
-
Copy full SHA for 80d4a8c - Browse repository at this point
Copy the full SHA 80d4a8cView commit details -
Configuration menu - View commit details
-
Copy full SHA for 4cfec39 - Browse repository at this point
Copy the full SHA 4cfec39View commit details -
Fix many errors in types preview
- Improve the way we do a minimal representation of the Ember Object primitives and utilities. - Introduce our own copy of `@ember/string`. - Start workk on many of the tests for `Ember` namespace re-exports. - Stop distinguishing between Octane and everything else: we only care about Octane anyway in our public *TS* API, per RFC 0800.
Configuration menu - View commit details
-
Copy full SHA for 44225d2 - Browse repository at this point
Copy the full SHA 44225d2View commit details -
Configuration menu - View commit details
-
Copy full SHA for 3a3f44f - Browse repository at this point
Copy the full SHA 3a3f44fView commit details -
Configuration menu - View commit details
-
Copy full SHA for d74ec00 - Browse repository at this point
Copy the full SHA d74ec00View commit details -
Configuration menu - View commit details
-
Copy full SHA for f02fade - Browse repository at this point
Copy the full SHA f02fadeView commit details -
type test fixes for 'ember-tests'
This file is a hot mess, and provides more and further evidence of two increasingly-obvious realities from a TS POV: - The Ember namespace is 99% useless; people should just use the module imports instead. - The Classic types are *awful*, because Classic *code* was a mess compared to Octane, because ES5 was a mess.
Configuration menu - View commit details
-
Copy full SHA for af95f0c - Browse repository at this point
Copy the full SHA af95f0cView commit details -
Configuration menu - View commit details
-
Copy full SHA for 50ba435 - Browse repository at this point
Copy the full SHA 50ba435View commit details -
Configuration menu - View commit details
-
Copy full SHA for 4318136 - Browse repository at this point
Copy the full SHA 4318136View commit details -
Configuration menu - View commit details
-
Copy full SHA for 0ac44ad - Browse repository at this point
Copy the full SHA 0ac44adView commit details -
Configuration menu - View commit details
-
Copy full SHA for ae59a59 - Browse repository at this point
Copy the full SHA ae59a59View commit details -
Configuration menu - View commit details
-
Copy full SHA for 2939f49 - Browse repository at this point
Copy the full SHA 2939f49View commit details -
Configuration menu - View commit details
-
Copy full SHA for d29df63 - Browse repository at this point
Copy the full SHA d29df63View commit details -
Configuration menu - View commit details
-
Copy full SHA for d21c1dc - Browse repository at this point
Copy the full SHA d21c1dcView commit details -
Configuration menu - View commit details
-
Copy full SHA for 16855e9 - Browse repository at this point
Copy the full SHA 16855e9View commit details -
Configuration menu - View commit details
-
Copy full SHA for 25462e1 - Browse repository at this point
Copy the full SHA 25462e1View commit details -
Configuration menu - View commit details
-
Copy full SHA for c3b9e5a - Browse repository at this point
Copy the full SHA c3b9e5aView commit details -
Configuration menu - View commit details
-
Copy full SHA for d52d1ca - Browse repository at this point
Copy the full SHA d52d1caView commit details -
Configuration menu - View commit details
-
Copy full SHA for ad2a026 - Browse repository at this point
Copy the full SHA ad2a026View commit details -
Configuration menu - View commit details
-
Copy full SHA for f3cfdd5 - Browse repository at this point
Copy the full SHA f3cfdd5View commit details -
Configuration menu - View commit details
-
Copy full SHA for e8a33f3 - Browse repository at this point
Copy the full SHA e8a33f3View commit details -
Configuration menu - View commit details
-
Copy full SHA for a44f30e - Browse repository at this point
Copy the full SHA a44f30eView commit details -
Configuration menu - View commit details
-
Copy full SHA for cd4da05 - Browse repository at this point
Copy the full SHA cd4da05View commit details -
Configuration menu - View commit details
-
Copy full SHA for 69aa362 - Browse repository at this point
Copy the full SHA 69aa362View commit details -
Introduce type utilities for safe
get(Properties)
These allows us to make `get` or `getProperties` correctly handle index access the same way direct field access would. This gets us back to the same level of safety we had with our old `UnwrapComputedProperty*` types for this kind of index access: those types did *many* things, but included among them was distributing across the requested properties.
Configuration menu - View commit details
-
Copy full SHA for b4a6d2c - Browse repository at this point
Copy the full SHA b4a6d2cView commit details -
Configuration menu - View commit details
-
Copy full SHA for 3b04c24 - Browse repository at this point
Copy the full SHA 3b04c24View commit details -
Ignore a case where Ember.get is distinct from get
While we would prefer this to work, it is not a hard necessity, for (at least) two reasons: 1. Use of `Ember.get` vs. the import from `@ember/object` is rare and should be discouraged. 2. Use of `get` is itself fairly unusual to *need* these days; most uses either will not hit this case, as in the deep key lookup (which is always just `unknown` anyways) or should be trivially replaced with direct property access (since Ember 3.1!).
Configuration menu - View commit details
-
Copy full SHA for 82c4efa - Browse repository at this point
Copy the full SHA 82c4efaView commit details -
Simplify handling of preview types for get(Properties)
Unlike in the previous pass, this does not try to handle index access 'correctly', instead choosing to just push people to use normal JS if they want that safety.
Configuration menu - View commit details
-
Copy full SHA for 11a144f - Browse repository at this point
Copy the full SHA 11a144fView commit details -
Finish getting preview types type checking
- fix runloop test - provide an internal-only type for Resolver` that should be compatible with the one in `@types/ember-resolver`
Configuration menu - View commit details
-
Copy full SHA for c16c707 - Browse repository at this point
Copy the full SHA c16c707View commit details -
Configuration menu - View commit details
-
Copy full SHA for 76d0b62 - Browse repository at this point
Copy the full SHA 76d0b62View commit details -
Implement publishable types preview layout
1. Introduce a root import, `types/preview/index.d.ts`, which itself imports every module which is part of Ember's type definitions. Then wrap each module definition in a `declare module '<name>' {}` so that importing it makes the module visible in the type system. This makes it so that users can use the types by simply writing a single import: ```ts import 'ember-source/types/preview'; ``` This approach will scale forward to all sorts of future work in TS in Ember, including publishing at `ember-source/types/stable`, or for future editions e.g. at `ember-source/types/polaris`. Moreover, this allows these to happen *simultaneously*. That is, as we publish types from source, those can go directly into the `stable` directory and users can simply have both imports present: ```ts import 'ember-source/types/preview'; import 'ember-source/types/stable'; ``` Similarly, because this relies on module declarations, module merging works and this will allow us to at some point publish stable types supporting *only* new editions, with the default type import being at `stable` but users being able to opt into types which support the old edition: ```ts import 'ember-source/types/stable'; import 'ember-source/types/classic'; ``` 2. Extract the type tests for the published types into a `type-tests` directory, which actually *uses* those mechanics to validate that the types are all importable and usable as expected with that single import statement. Do *not* include that directory in `files` in `package.json`, so the tests are never published, only the type definitions themselves. Making those changes and getting the test suite passing also highlighted a number of errors in the existing type definitions (and tests!) for `EmberArray` and its related types, which had historically been masked by the way our tests incorporated the prototype extensions: *all* arrays appeared to act as a `NativeArray`. Fixing that involved pulling those type tests out into a dedicated test package, and then fixing all the bugs in the existing type definitions, including restructuring to match the *actual* structure of Ember's internals. However, fixing the *regular* types for arrays *also* highlighted that it is currently impossible to properly represent the array prototype extensions. Accordingly, those are excluded from this, and will be addressed in some other way.
Configuration menu - View commit details
-
Copy full SHA for 6636579 - Browse repository at this point
Copy the full SHA 6636579View commit details -
Configuration menu - View commit details
-
Copy full SHA for e320eaa - Browse repository at this point
Copy the full SHA e320eaaView commit details -
Add array prototype extension preview types
These *do not work*. They will be removed in the next commit, but are added here for historical purposes. They do not work specifically because they introduce a circularity in the definition of `NativeArray`: `NativeArray` must extends from a *subset* of `Array` to correctly represent its public API and behavior, but introducing the `Array` prototype extension in turn must extend from `NativeArray`, which results in type errors because `NativeArray` extends from the subset rather than the full API of `Array`. This "worked" in the DefinitelyTyped version for two reasons: 1. All of our type tests actually just assumed the array prototype extensions were enabled (as discussed in the previous commit). 2. The type definition for `NativeArray` was *wrong*: at minimum it was substantially out of date; possibly it has always been incorrect. (It may have been incorrect *intentionally*, precisely to allow the prototype extension to work. The details are lost to time.) In any case, these type tests represent the "correct" APIs for the prototype extensions, so are committed here and removed in the next commit for historical purposes.
Configuration menu - View commit details
-
Copy full SHA for 074ad88 - Browse repository at this point
Copy the full SHA 074ad88View commit details -
Remove types for array prototype extensions
See previous commit message for discussion of *why* these are being removed. If we decide to re-introduce these types later, it will require not only adding back in these tests but also taking some fairly distinct approach to their inclusion, given the problems with the way they work.
Configuration menu - View commit details
-
Copy full SHA for 6b64fb2 - Browse repository at this point
Copy the full SHA 6b64fb2View commit details -
Configuration menu - View commit details
-
Copy full SHA for 75b6126 - Browse repository at this point
Copy the full SHA 75b6126View commit details -
Types preview: import from 'ember-source/preview'
Use `typesVersions` to resolve `preview` to `types/preview`; we can use `types` for stable and more `typesVersions` (or, eventually, `exports`) for other similar schemes in the future.
Configuration menu - View commit details
-
Copy full SHA for 6c75ebe - Browse repository at this point
Copy the full SHA 6c75ebeView commit details -
Types preview: remove private DT route types
We continue to maintain support for these import locations in the types on DefinitelyTyped, but remove them here so that users trying the preview types do not accidentally depend on them.
Configuration menu - View commit details
-
Copy full SHA for b12893c - Browse repository at this point
Copy the full SHA b12893cView commit details -
While having some guidance for the ambient types here would be needful for the long term, we do not intend to *keep* these all that long; this is intended as transitional. If we end up maintaining the ambient types for a long time, we can of course revisit this. In any case, we will want to run linting on any type tests we introduce for *stable* types (at a future `type-tests/stable` location). Net, exclude everything in `types` and the tests in `type-tests/preview`.
Configuration menu - View commit details
-
Copy full SHA for 87b7cf5 - Browse repository at this point
Copy the full SHA 87b7cf5View commit details -
Types preview: remove dead imports
The corresponding module declarations were removed earlier; this simply drops the 'side-effect' imports from `types/preview/index.d.ts`.
Configuration menu - View commit details
-
Copy full SHA for 99350b7 - Browse repository at this point
Copy the full SHA 99350b7View commit details