-
Notifications
You must be signed in to change notification settings - Fork 25.6k
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
Typings files in alpha.46 #5248
Comments
It appears to me that these d.ts files reside at the top level of the NPM package. Happily, Visual Studio code appears to find them there just fine. I'm sure there's some documentation somewhere explaining the following, but unfortunately I do not know where. It is unclear to me when sifting through MPM packages, which typing's go where. But I think the files you're talking about are the typings for Angular's dependencies, while the typings for Angular itself are where I pointed out. |
@thelgevold this is on purpose: we no longer distribute bundled typings for ng2 but rather allow TS to discover them from node_modules (typings are located next to source files). See https://github.com/Microsoft/TypeScript/wiki/Typings-for-npm-packages for more info |
Just a heads up to any Visual Studio (not VSCode) users, the default classic resolution wont work because |
- EventEmitter is now generic and requires a type [angular/angular#4893] - EventEmitter and Observable now use the .subscribe(generatorOrNext, error, complete) method instead of .observer(generator) [angular/angular/pull/4893] - tsconfig: set `moduleResolution: node` - angular/angular#5248 - imports: switch to file-relative paths
- npm: update dependencies - AuthService, TaskStore: EventEmitter is now generic and requires a type [angular/angular#4893] - AuthService, TaskStore: EventEmitter and Observable now use the .subscribe(generatorOrNext, error, complete) method instead of .observer(generator) [angular/angular/pull/4893] - tsconfig: set `moduleResolution: node` [angular/angular#5248] - imports: switch to file-relative paths - docs: update readme
- AuthService: EventEmitter is now generic and requires a type - AuthService, TaskStore: EventEmitter and Observable now use the .subscribe(generatorOrNext, error, complete) method instead of .observer(generator) - imports: switch to file-relative paths - npm: update dependencies - tsconfig: set `moduleResolution: node` [angular/angular#5248] - docs: update readme
We don't use NPM because we are in an MSBuild environment in Visual Studio. All we used was the bundled d.ts file. Is using node mandatory now? Unfortunately that doesn't fit in our build chain ... What we currently did was check in the typings file and the js file somewhere in the "thirdparty" part of our source code tree (it's huge). In the build step for "thirdparty" those files were just copied to the output folder. In our visual studio project we then made a link to the typings file in the build folder. This link ensures us 2 things: The typings work in our project and in the post-build step the js bundle belonging to this typings file is included in our web archive. I have no clue how we should do this without a typings file. I feel a bit reluctant to check in an entire node_modules folder when all I need is a typings file and a corresponding js file. Can I build the previously bundled d.ts file myself? @pkozlowski-opensource |
Thanks, I think this change makes sense now that I am aware of it :-) @woppa684 : I think you can still keep your current workflow since you can cherry pick the typings files you need from the node module and add those to your third party folder. I get mine from the node module now, but you can put the files wherever you want. |
@woppa684 if you're not using NPM, how are you getting your hands on the ng2 distribution exactly? That's not to say we won't, but I don't think we have a story for this yet. Could you (and other non NPM types) describe a little your expected / normal workflows? |
Ok @robwormald, let me explain a bit ...First of all, let me say that It's hard to describe our build workflow without giving too much detail or violating some NDA ;) As a software designer at Canon I am responsible for the user interfaces of several product lines of digital production printers. In our current product we have a variety of different user interfaces (java swing based, java struts based, angular 1.x based). Our future UI will be web-based and has to work on all kinds of devices and screen sizes. We want to use Angular2 for that obviously :) Since we're working in a very large codebase with a lot of engineers we want to use TypeScript and integrate that with our current build enviroment. We all work with Visual Studio and MSBuild. Our MSBuild environment is relatively strict since we will not allow custom build scripts (ant, grunt etc) to run. If we want to add a custom build step (say, for example, add js minification) an extra option will be added to our own tab in the vs project properties to enable this (this will then trigger some tool that will do the minification in a post-build step). All our thirdparty dependencies (so, for the entire platform) reside in a separate solution. Our UI subsystem has a dependency to that subsystem then of course. So, what we need to do in the build step for the "thirdparty" subsystem is make sure that the dependencies the "ui" subsystem needs are in place. I don't want engineers to be able to define their own dependencies other than linking to typings files somewhere else in the tree. I also don't want to have to download some node_modules folder I don't need on our build servers and on every engineers pc (that I then have to add to the .tfignore of course else it will probably get checked in some day). Another option is to automatically copy all source code to an intermediate folder and do the NPM install there but it seems like a real hassle to do that every single time. Also, like I said, it's not needed. We want to be dependent on a specific version of software (yes I know it can be specified) that we have in our own source control so that we can do a controlled upgrade when needed. Last but not least, this still doesn't help Visual Studio of course (where I need to link to the d.ts file). I'm a bit lost... What is your plan for very large applications and build workflows then? How do they do it in, for example, AdWords? Currently I will stay on Alpha45 until we have a solution... Oh, and to answer your question, I NPM installed angular2 locally and put the contents of the bundles folder in source control of course... :) |
@woppa684 thanks for the detailed explanation. The preferred option for angular distribution going forward is going to be NPM. there's a few reasons for this, primarily that its used by the vast majority of the JS ecosystem already. That said, you could certainly do what you're doing (gross, though, for real... ;-) Your actual question though is about typings, and that's a more complex thing. Typescript 1.6 introduced a new way of handling typings, and this is what we're working with. Rather than the "ambient" style modules, which look like: declare module {} typescript .d.ts files now mirror their source files - they're effectively ES6 version of import { RequestOptionsArgs, ConnectionBackend } from './interfaces';
import { Request } from './static_request';
import { RequestOptions } from './base_request_options';
export declare class Http {
protected _backend: ConnectionBackend;
protected _defaultOptions: RequestOptions;
constructor(_backend: ConnectionBackend, _defaultOptions: RequestOptions);
request(url: string | Request, options?: RequestOptionsArgs): any;
} The first (incredibly great thing) this enables is developers to not have to mess with
import {Component} from 'angular2/angular2' and everything pretty much works. This works because typescript's new module resolution algorithm works the same as NodeJS's, and so the NPM distribution looks like:
This algorithm currently assumes that your vendor code is in a Now - the biggest change here is that instead of a monolithic single This changes the build strategy you mentioned (that is, compile everything in foo/* ) into a much more intelligent way of building. If I had a //main.ts
import {bootstrap} from 'angular2/angular2' //npm
import {SomeOtherDep} from 'my/awesome/dep' //npm
import {MyComponent} from './components/MyComponent' //local
bootstrap(MyComponent); Rather than saying "concat and minify all the stuff in vendor, and then concat all the stuff in The two leaders in this bit of tooling are currently Webpack and JSPM, but TypeScript has bundling on their roadmap to accomplish the same goal. Now - we will continue to distribute bundled JS code - but is not certainly not the preferred method for consuming angular2. As of now, there isn't a great solution for us re-bundling the The Angular2 bundles that exist today are primarily for ES5 users, and for making plunkers and demos easier to get online, but they are not the recommended solution for (eventual!) production usage. I would strongly suggest moving towards the modern way of working with Javascript modules. I realize that's easy for me to say and less so for you to flip the switch on, but as Angular2 is trying to be forward-looking, it is where we will concentrate our efforts. Hope that explains more that it confuses - we definitely want to enable a variety of use cases here, so happy to continue discussing if you have more questions. (ps - use NPM. you'll love it.) |
p.p.s - if you're in the sort of constrained environment where you have to submit a request to use a third party dependency, NPM has the option of maintaining an internal registry (there are a number of free / open source and hosted / non-free solutions for this) - see https://www.npmjs.com/onsite for example. This is a great option for large orgs, especially as they begin towards using ES6 and modern Javascript in general. Just a thought. |
Rob - I have been following the various machinations in trying out the various alternative tools around everything you wrote about above, and by the way that was an excellent summary that should be widely distributed. But the following would also be very helpful, if it is possible. For those cases when it is helpful to distribute a modest pile of files and have things "just work" even with typescript, we are already there, even for something like a plunkr, using JSPM. A couple of files of overhead, and Angular bundle or two, the typescript compiler itself in one file, etc. "Legacy" typings were also conveniently supplied as a single d.ts file for most libraries. That used to be available for Angular 2, until the recent division into numerous small d.ts files as you described. It would be very helpful if the Angular 2 distribution could somehow also include, or make available otherwise, a single-file d.ts to get a good typescript development experience in these cases where we would like to get up and running with just a few files. Pointless for production, but very useful for introducing people to Angular 2. |
@kylecordes thanks - JS modules / bundling have more or less consumed the last year of my life, so I've practiced that speech a few times by now ;-) RE: "just work" - I take your point, but from the inside, nothing "just worked" about the process we were using previously - we were using our documentation generator to build a In the short term, we're re-organizing our bundling strategy slightly - see #5223 - and so it might be possible to build a In the medium term, our command line is going to be the easy onboarding strategy - we'd like that to handle all the shenanigans for you wrt to bundling / deployment. |
Also, wrt to JSPM specifically (of which i am a huge fan, btw) - microsoft/TypeScript#5039 should allow it to work nicely without the need for manual |
@robwormald: I agree with @kylecordes, you should publish this summary as a blog post somewhere and not leave this nice summary buried :p. Personally, I'm still putting my hopes on JSPM though I'm wondering if Webpack isn't the best solution out there for bundling for now (haven't had time to play with it yet). The lack of a 'jspm_resolution' mode for TS typings is what makes it annoying for now (having to duplicate my dependencies with NPM just to get the TS compiler happy). Anyhow, now that I've seen the light, there's no way I'll ever get back to manually adding third party code to my projects, add script tags manually or using /// references (that felt sooooo hacky & unstable). The difficult part now for the JS community will be to convince everyone that they should bundle the typings and forget about DefinitelyTyped (or find a good measure between both). For example I discussed this with the Firebase guys but they didn't seem very enthusiastic (a real shame ^^) although it's so easy to add to a project published on npm.. |
@dsebastien it is with a heavy heart that I currently use Webpack for all my demos (kidding really, Webpack is pretty awesome) - I'll reevaluate once resolution is configurable in TS. I've got a sample project here from a workshop I did a little while back that has a simple webpack/ng2 setup, with livereload. I especially like the fact that webpack dumps TypeScript errors into the terminal with lots of pretty colors when I screw up. Do feel free to check it out. |
Yeah I will do it for work, we're still exploring the options out there :) On Mon, Nov 16, 2015 at 9:09 AM, Rob Wormald [email protected]
|
@robwormald What would you recommend currently? I don't really want to constantly switch back and forth and I just go comfortable with JSPM and SystemJS (really like it). But like others in alpha 46 I am running into the same issues related to typing files not loading, and having to duplicate the dependency in both JSPM and NPM. Do you think going with webpack would be a better choice going forwards? |
For the moment, I'm using webpack till Typescript is configurable. That said, there will probably be three new tools by next month (because javascript) so its hard to make a concrete recommendation ;-) |
@robwormald I might just try out webpack or go down the route I was thinking of first. Doing everything within SystemJS manually (only concerned with the amount of configuration I might have to do). |
@robwormald A few weeks ago I saw Now with alpha46 I can't compile anymore ( My tsconfig:
I have changed the
but it seems the compiler (in classic resolution mode ) doesn't understand the new .d.ts format. My question: Isn't there currently any way to use alpha46 with import paths relative to the tsconfig containing folder (
Do you mean, with VSCode there is no problem? |
@hristokostov if you use |
@dsebastien Thank you for your quick reply. I know I don't need triple-slash references if I use |
Oh okay, good thinking :) The good news is that the TS team is now busy implementing that.. |
@robwormald In Bash at my project directory, when I enter - npm install angular2 - I see several file GETs and then see " 'reactivex' is not in the npm registry, You should bug the author to publish it. It was specified as a dependency of 'angular2' " When I enter - bower install angular2 - I get angular 1.4.8 installed, not angular2. As I understand the above comments, typescript now depends on installed angular2 in the project files. Anyway, I'm getting lots of atom-typescript errors when I use syntax and entities in alpha.46. Am I messed up, or does the angular2 install process need more work? |
@mLaird sounds like you have an out of date version of NPM.
|
@robwormald , thanks. I changed from Win7 to Win10 recently. I downloaded node.js afresh, and npm seems to be working - I got the recent alpha.47 OK. Thanks, again. |
Just a quick question, the rest of the dependencies that need typings (es6-shim and others), will those be referenced in angular2 or do we have to make sure we include them? |
For the time being we decided to create an MSBuild task to copy all needed d.ts files to a node_modules folder in the source folder during a PreBuild step. Users of this build system are only allowed to specifiy the node modules their project depends on, the PreBuild step will do the rest. Of course we had to add 'node_modules' to .tfignore so it doesn't end up in version control ... #5796 looks promising together with microsoft/TypeScript#4433 by the way. |
- npm: update dependencies - AuthService, TaskStore: EventEmitter is now generic and requires a type [angular/angular#4893] - AuthService, TaskStore: EventEmitter and Observable now use the .subscribe(generatorOrNext, error, complete) method instead of .observer(generator) [angular/angular/pull/4893] - tsconfig: set `moduleResolution: node` [angular/angular#5248] - imports: switch to file-relative paths - docs: update readme
- AuthService: EventEmitter is now generic and requires a type - AuthService, TaskStore: EventEmitter and Observable now use the .subscribe(generatorOrNext, error, complete) method instead of .observer(generator) - imports: switch to file-relative paths - npm: update dependencies - tsconfig: set `moduleResolution: node` [angular/angular#5248] - docs: update readme
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
It appears that the Angular2, http and router typings files are no longer included in the npm package under bundles/typings.
Are they hosted somewhere else now?
The text was updated successfully, but these errors were encountered: