ERROR in [default] \node_modules\angular2-logger\app\core\logger.ts:62:38 Type 'string' is not assignable to type 'Level'.
Closed this issue · 39 comments
This problem appeared with angular2-logger 0.3.0 after I updated to Angular 2 rc5.
I just updated angular2-logger to its latest 0.4.2 and the problem still shows up.
ERROR in [default] \node_modules\angular2-logger\app\core\logger.ts:62:38 Type 'string' is not assignable to type 'Level'.
Changing the line from:
private _loadLevel = (): Level => localStorage.getItem( this._storeAs );
to
private _loadLevel = (): any=> localStorage.getItem( this._storeAs );
seems to resolve the problem.
Hi @vkniazeu ,
This issue appeared in a Typescript upgrade, not angular2-logger upgrade. See #39. If you use the latest officially released version of Typescript 1.8.10 you won't see it.
It should be fixed in 0.4.2 even for newer versions of Typescript though, if you are following the Quickstart guide. Somehow you are pointing to the logger.ts when you should only be using the typings ( core.d.ts ) as the library is already compiled, you don't have to compile it again.
Is there a step you are doing different from the Quickstart guide?
Hi @langley-agm,
Thank you for such a quick reply and for a great logging utility!
I apologize I haven't found the original issue before opening this one and for the fact that I've been updating various aspects of my app, so I assumed a wrong thing.
I am using "angular-cli": "1.0.0-beta.11-webpack.2", which was recently ported over from SystemJS to webpack, which, I admit, is a much welcomed change and improvement IMHO.
That version of angular-cli requires Typescript 2.0.0, but I completely understand it's not an official release yet.
Step 2 of the Quickstart guide does not apply to webpack.
The way it handles typings under the angular-cli setup, is via the following in tsconfig.json:
"typeRoots": [
"../node_modules/@types"
],
I am not referencing or pointing to logger.ts explicitly in any way.
Just importing and listing the relevant classes in the providers array of the main app's module:
import { LOG_LOGGER_PROVIDERS, Logger } from 'angular2-logger/core';
...
providers: [
Logger, LOG_LOGGER_PROVIDERS,
]
...
Thank you for your help and insight!
If this issue is a duplicate and not related to angular2-logger, please close it.
Thanks for the kind words @vkniazeu.
Sadly I haven't been able to dig into webpack, there's just no way to sanely keep up with so many different frameworks poping up by the day and Angular Team not making up their minds about them doesn't make it any easier.
The root cause of this issue is the fact that Typescript is trying to compile a third party library in the first place. I don't think there's any other language that does that. The library is compiled in 1.8.10 and people should be able to use it in newer versions if they want to without finding these kind of conflicts. You already have the compiled files in the distribution, source files are merely for reference. That's why I don't want to just apply a change like the one you suggested because it will be hiding the real problem.
The Quickstart is based off the Angular 2's Quickstart which uses SystemJS so I applied a fix for it.
I'm thinking this is an issue on Webpack configuration but I haven't used it yet so I can't confirm it, if someone finds something missing in this repo that webpack needs in order to use the compiled files and not the source files I'll hapily look into it.
How are you telling webpack where to find 'angular2-logger/core' ? Is there a way to tell him to use either the .d.ts or even the js files instead of the ts files ?
One more thing I can think of that might be affecting / could help with this is the main and typings attribute in this library's package.json file.
@langley-agm, I am fairly new to Typescript and brand new to webpack, but my understanding is that it goes through all .ts files referenced in your main.ts file and its children and uses the import statements to to bundle up any and all references withing your code.
There's no explicit webpack configuration within your project. Some people actually complain about the fact that the config is part of angluar-cli/webpack bundle and cannot be controlled manually, which imposes some restrictions.
Essentially, the only relevant file under your control is tsconfig.json, which is as simple as the following:
{
"compilerOptions": {
"declaration": false,
"emitDecoratorMetadata": true,
"experimentalDecorators": true,
"lib": ["es6", "dom"],
"mapRoot": "./",
"module": "es6",
"moduleResolution": "node",
"outDir": "../dist/out-tsc",
"sourceMap": true,
"target": "es5",
"typeRoots": [
"../node_modules/@types"
],
"types": [
"jasmine"
]
}
}
Many other packages like lodash, protractor, etc. seem to be putting their typings under node_modules\@types. Other packages, like angularfire2 seem to have updated their structure recently where external typings config is no longer required. They host only .js and .d.ts files within the package, not the source .ts.files.
On a separate note, aside from all the configuration and typings, wouldn't any strong type language compiler complain about the fact that your function is marked as returning a number (Level) while it actually returns a string in this line without any proper casting or a similar conversion?
private _loadLevel = (): Level => localStorage.getItem( this._storeAs );
Many other packages like lodash, protractor, etc. seem to be putting their typings under node_modules@types.
@types is a corporate name in NPM which holds different projects: https://www.npmjs.com/~types, you don't put your definitions there, you create a project there with the definitions, however this is useful for libraries that are not typescript.
If you notice lodash, protractor are js libraries not Typescript libraries, that's why you need the typings from a TS library which has no code but the definitions ( .d.ts files ), that's what typings mean. When you use these "libraries", you tell Typescript what's ok and what's not, without actually having the ts code of the js library, cause there's none. If your project is written in Typescript, it makes little sense to create a whole different project for the definitions only, that's why you import Angular 2 code from @angular and not @types, @angular is the corporate namespace in npm for the Angular Team projects going forward, this was done recently to avoid people from different companies not being able to name their projects with the same name. Another example is https://www.npmjs.com/package/%2540reactivex%2Frxjs.
Other packages, like angularfire2 seem to have updated their structure recently where external typings config is no longer required. They host only .js and .d.ts files within the package, not the source .ts.files.
Angular Team seems to be doing this, I don't know if just because it makes things easier for them or what, but they used to include them, RxJS does include them ( https://github.com/ReactiveX/rxjs ) and I definitely see a use case on including them, its been an innumerable number of times in which I've had to read Angular 2 source code and I see no reason why I should go to the Github and search for the code manualy when you can just have it there in your project and your IDE point you to them. Whether you download the source code or not should be a user's desicion imho, that's how other package managers work.
On a separate note, aside from all the configuration and typings, wouldn't any strong type language compiler complain about the fact that your function is marked as returning a number (Level) while it actually returns a string in this line without any proper casting or a similar conversion?
Well this is a decision on the language's creator/s. In Typescript 1.8.10 this isn't necessary, in newer versions it is. If I move my project to a newer version of Typescript I'll make sure to update that file. However, the typescript version in which this library is compiled, should not affect the project in which you use it, cause it is already compiled into JS. Again, whether this is correct or not, doesn't matter, the root cause of this issue is the fact that your project is trying to compile Third Party .ts files, you should not be forced to do this.
What happens if you try this? :
"typeRoots": [
"../node_modules/@types",
"../node_modules/angular2-logger"
],
The latter suggestion didn't help, but it's okay.
I owe you not one, but a case of beer, for such an educational explanation! :)
To your point of having to go to Github to see the source, I get it and by no means I'm arguing, but shouldn't the JS (complied code) and the type definitions (= public interface to the package) normally be enough to use a module? I mean, if it weren't open source, that's all you'd get, right - just the publicly exposed interfaces?
Again, not arguing at all, but the technically the source code of a third-party module can be looked at something that should only live in their repo and not in the actual package that gets pulled to all the devs' machines.
Perhaps I'm misunderstanding something, but I hope I don't catch myself setting break points in the third-party modules to debug their Typescript implementation too often :))
shouldn't the JS (complied code) and the type definitions (= public interface to the package) normally be enough to use a module?
enough? yes, I'm not trying to go for what's the minimal enough though, if its useful for some users to have the source files there i'll leave them there. Like I mentioned other package managers have a flag to decide whether to include the source files in the downloaded packaged library or not, this is a lacking functionality in npm, however this is nowhere near the scope of this issue.
@vkniazeu If you are able to share your repo I can take a look at it, otherwise you could probably reproduce it in a small project that I do have access to. Not sure how hard it would be to do it in something like plunkr, probably its just easier to create a demo project in github because of all the dependencies and setup required in angular 2.
@langley-agm, here's a minimal CLI webpack setup to reproduce the error.
It's just the output of the bare-bones setup listed at https://github.com/angular/angular-cli, with angular2-logger added to package.json and to app.module.ts.
npm install -g angular-cli
ng new test-cli
cd test-cli
ng serve
Download: test-cli.zip
Reproducible with "angular2-logger": "0.4.5".
Yea, no real changes in these minor releases yet, I was just trying to fix some stuff rendering wrong from the .md file. It looks fine now in GitHub but npm still doing weird stuff with it.
The test setup posted by @vkniazeu will actually install the outdated SystemJS version of the cli. A better setup is the following:
npm install -g angular-cli@webpack
ng new test-cli -lc
cd test-cli
ng serve
Also note the -lc (aka --link-cli) switch which links the new project to the globally installed CLI instead of creating a local duplicate. Linking is probably a good idea in most cases.
Edit: Oops, disregard the next two paragraphs. Obviously we want to use the ES6 dist for CLI production builds because tree-shaking algorithms (removing unused code paths) work best with ES6 modules.
You can load an arbitrary script by putting it in the scripts section of your angular-cli.json file. For example,
"scripts": [ "../lib/angular2-logger.sys.min.js" ],
However, my angular-cli project was not able to load modules from it (I added the definitions in a declare module 'angular2-logger' { ... } block in my typings.d.ts and erased the node_modules/angular2-logger folder.) It might not support SystemJS's module format, and there are currently no hooks into the built-in webpack config to customize the build process (although it's a planned feature.)
One thing I haven't tried yet, though, is enabling "compileJs" in the typescript config and then referencing the bundled module with a relative path. Maybe it needs to be processed by the Typescript engine for the CLI's webpack build to pick it up properly?
Solution (Hack)
- Copy
core.d.tsfromnode_modules/angular2-loggerintonode_modules/angular2-logger/dist/es6 - Use the es6 dist path in your import statements. Here are two examples:
import { Logger } from 'angular2-logger/dist/es6/core';import * as logger from 'angular2-logger/dist/es6/core';
Conclusion
The angular CLI won't automatically pick up the es6 dist & core.d.ts, it needs both to be in the same directory and be pointed directly at it. If you have a look through node_modules\@angular\core (or any of them) you'll notice there are no .ts source files anymore, they were removed. Maybe that's just how Angular libraries are supposed to be structured? Or maybe there's a setting to configure it...
@langley-agm Just so you know, I don't believe this or #39 are related to type-bundling at all. According to the docs, .ts files take precedence over .d.ts files during module resolution at compile-time.
...
...
Source: https://www.typescriptlang.org/docs/handbook/module-resolution.html
In other words, core.ts takes precedence over core.d.ts at compile-time and it resolves the types by compiling the source.
Just so you know, I don't believe this or #39 are related to type-bundling at all.
No one said otherwise =)
According to the docs, .ts files take precedence over .d.ts files during module resolution at compile-time.
This is why there's no core.ts file in the distribution now.
import { Logger } from 'angular2-logger/dist/es6/core';
This is not what we're aiming for.
If you have a look through node_modules@angular\core (or any of them) you'll notice there are no .ts source files anymore, they were removed. Maybe that's just how Angular libraries are supposed to be structured? Or maybe there's a setting to configure it...
I noticed. However no one knows how Angular libraries are supposed to be structured yet, like you just mentioned even the Angular team keeps changing this structure. As reference you can see other typescript libraries like RxJS do include the .ts files, It is useful to have those in the distribution.
Heya, @langley-agm!
This is why there's no core.ts file in the distribution now.
Ah, I see your rational. I don't know about other build processes, but the angular-cli still has a habit of finding the .ts versions and using them. Not entirely sure why it does this, I guess they internally set the allowjs flag or something. Look at the file path that's giving me the error:
I'm currently using typescript@2.0.2 and the master branch of the angular-cli.
Just so you know, I don't believe this or #39 are related to type-bundling at all.
No one said otherwise =)
Ok, I skimmed through #39 and thought that's what you were saying at the end. It's a pretty long thread.
At the end, you talked about separating the .d.ts files from .ts files as a potential solution. I don't think that will make any difference though, because it looks like the CLI is set up to compile a .ts whenever it's in the same folder as a .js.
You can see the difference by doing that little copy-paste hack with the ugly import statement I posted. Since the dist/es6 folder doesn't have any competing .ts files, it just uses the .js and doesn't try to compile anything.
I have a better solution now that involves some refactoring. I'll push it into a fork a bit later so you can tell me what you think.
At the end, you talked about separating the .d.ts files from .ts files as a potential solution. I don't think that will make any difference though.
It made a difference, and it closed the defect, that defect wasn't about angular-cli, if you follow the regular quickstart guide you won't see this issue.
In this case angular-cli is making typescript use the .ts files instead of the .dts, why? that I don't know yet. I took a look at it but the documentation seems to be outdated, its obviously in constant change because angular 2 is in constant change. Once they get to a more stable position and update their documentation I'll take a look again to see if I can help finding out the right configuration when using angular cli to avoid this issue. Once again, you should not be compiling third party code. It's already compiled for you.
Note:
To clarify your confusion about the dts bundling. The reason I mentioned that is because I created the bundle semi-manually atm in order to close #39, this step should be done as part of the build process once typescript closes the issue that doesn't allow to do this.
In this case angular-cli is making typescript use the .ts files instead of the .dts, why?
Because it's compiling. It's looking for .ts files. The types resolve while you're writing code, but break at build-time. The only thing strange is that angular-cli is using ts files when the index was a js, and I think that's a bug.
To clarify your confusion about the dts bundling...
I'm not confused. To clarify your confusion, bundling declarations completely irrelevant. Just have your project compile with --declaration into a spot module resolution will find it. If you don't want to, just set "typings" in package.json to your root index.d.ts file, wherever you decided your output should go.
At the end, you talked about separating the .d.ts files from .ts files as a potential solution. I don't think that will make any difference though.
It made a difference, and it closed the defect, that defect wasn't about angular-cli, if you follow the regular quickstart guide you won't see this issue.
I see, your solution hacked node resolution by removing the file it's designed to check first. This is a strange problem to have in the first place. Excuse my confusion.
this step should be done as part of the build process once typescript closes the issue that doesn't allow to do this.
TypeScript is fine. Hopefully I can help, here's a working solution:
https://github.com/TheFirstDeity/angular2-logger/
I put some detail how it works:
https://github.com/TheFirstDeity/angular2-logger/blob/master/docs/dev/CHANGES.md
Then got sleepy. Probably forgot a thing or two explanations, open for questions/feedback.
I see, your solution hacked node resolution by removing the file it's designed to check first.
I didn't hack a solution. I applied a real solution one contributor recommended in order to give the user the ability to use this library typings without having Typescript forcefully compile a third party library that was already compiled in the first place.
TypeScript is fine.
No, is not, they recognized it themselves and they are working on this: microsoft/TypeScript#4433
I'm not confused. To clarify your confusion, bundling declarations completely irrelevant.
The fact that you are discussing two different issues as the same one makes me thing you are indeed confused.
Previously, the were many dts files along each corresponding ts file. When the library user imported a file, typescript would load the ts instead of the dts, and by doing so, compiling it. This had absolutely nothing to do with angular-cli. This was an issue for one simple reason:
Because of how typescript is built, it would force them to compile this third party library, which is not desired.
In order to avoid this, the core.ts / core.d.ts file that was previously importing itself files like "logger", now doesn't import anything but instead includes the whole definition of the entire core module. Since core.d.ts has no code but is only a bundle of definitions now, core.ts was not needed anymore and removed, this is not a hack, this is by design.
That's another defect and it's tested and closed already.
Because it's compiling. It's looking for .ts files.
Angular-cli doesn't compile, it configures your project so typescript compiles it.
Once again, if you follow the Quickstart guide you won't have this issue. And the quickstart guide compiles the code too, except it doesn't compile this third party library code, it only uses its typings to make sure you are using it correctly. You should be able to compile your code without having to compile third party libraries, that's nonsense, if your project uses 400 libraries and you already have the compiled distribution of those 400 libraries why would you want to recompile them all everytime you make any change to your code? you should be able to only compile your code just as you are able to do so with any other compiled language.
The issue here is to find out what's angular-cli configuring/doing different than the Quickstart Guide that makes typescript look for the .ts files instead of using the .d.ts. Again, the quick start also makes typescript compile the code and it does not have this issue, angular-cli is doing something different, I'm not saying its an angular-cli issue, I'm saying we need to find out what's doing different in order to find the root cause of this issue that's only happening now when using angular-cli.
Ooooooooooooooooooooooooooooooooooooooooooooooooooooh right!
I remember reading this now:
So a js imports a ts in TypeScript 2.0.2
Previously, the were many dts files along each corresponding ts file. When the library user imported a file, typescript would load the ts instead of the dts, and by doing so, compiling it. This had absolutely nothing to do with angular-cli.
Recall the order it checks things during module resolution. Yup, the ts files take priority.
Because of how typescript is built, it would force them to compile this third party library, which is not desired.
Don't worry, you can import libs without compiling them! I can show you how, if you'd like.
Basically your .d.ts files and .js files (compiled artifacts) should be in the same folder as each other. Keep your ts files somewhere else so they don't interfere.
That's what I did here: https://github.com/TheFirstDeity/angular2-logger/
Recall the order it checks things during module resolution. Yup, the ts files take priority.
I do recall it, the user points to angular2-logger/core when importing, core.d.ts is used since there's no core.ts file.
Don't worry, you can import libs without compiling them!
We already do this ! Please follow the Quickstart guide, not the angular-cli one, to see what were talking about.
We already do this ! Please follow the Quickstart guide, not the angular-cli one, to see what were talking about.
"We" who? The person who opened this issue is using angular-cli@webpack.
That's great you got it to work with the Quickstart, but the not what this issue is about. I came to try and help resolve this issue, and your hyper-defensive responses aren't helping anyone. Please, let's get back to the technical stuff and leave our egos at the door.
Since angular-cli@webpack builds using typescript 2, I think it makes sense that he would be getting that error. What do you think?
"We" who?
The person who actually helped fixing the root cause of the previous issue and me.
you're hyper-defensive responses aren't helping anyone.
I'm not being defensive I'm trying to make you see what the issue is, you are talking indistinctly between angular-cli and typescript compiling, its two completely different things, we need to understand that so we can fix this issue.
The person who opened this issue is using angular-cli@webpack.
I know that. That's why this issue is still open, and the one you keep talking about and saying its unrelated to bundling is already closed. You are the one discussing two different things and getting confused because of it. You are saying bundling doesn't have to do anything with 39, not with this one. I'm explaining why bundling was mentioned in 39 not in this one.
What I'm trying to make you see is that this exception has been previously fixed as far a Typescript compiling is referred to; By giving a bundle definitions file we give typescript all he needs in order to avoid having to compile this library. And the proof of that, is that the quickstart guide is using typescript just fine without throwing this exception (even if you use a newer version of typescript in your project). Absolutely nothing to do with ego =)
This issue is something related to typescript doing something different when configuring it manually and when using it through angular-cli. We need to know what's doing different when using angular-cli first. Is it using its own typescript configuration? Is it's build script moving things around? Why is it that this error appears when using angular-cli and not in the regular quickstart?
Let's find the root cause before we attempt to fix it, otherwise we're risking to merely patch it and hide the root cause just like we did on 39. If you agree please ping me in gitter and lets schedule some time when we can get together and discuss it, I'm totally up for that.
Since angular-cli@webpack builds using typescript 2, I think it makes sense that he would be getting that error. What do you think?
Here's a keypoint. Like I've mentioned so many times before, you should not compile third party libraries, it has a distribution already compiled, so it doesn't matter what version of typescript webpack is using, it should not throw this error if it should not compile it in the first place.
You need to be able to use a third party library written in a previous version than the one you are using because in the end whats actually going to be used is Javascript. If you are using 400 typescript libraries and suddenly there's a breaking change in a new typescript version and you update your code to use that new version you should not have to wait for those 400 libraries to update their codebase to the newer version as well in order for you to use that new version. Does this makes sense?
Cool cool, so we're back on track. Thanks for all the education I owe you a million beer. Now, I'd like to get your take on something that has me genuinely stumped.
So, my node_modules\angular2-logger\app\core folder looks like this:
When I compile, I get the error output from the title of this issue. Success!
However, simply removing the .ts files gives me the following unexpected result:
The green screen of death. What went wrong?
Embarrassingly, I have this problem in the fork I created. Every library I use seems to be the same story. However, I strongly suspect this issue has to do with everyone else's code, so I'm just waiting on all the open issues on GitHub before this is even possible to fix.
I'm totally down to discuss this for six pages of solid 6pt text! Just don't post any solutions, temporary or otherwise. We gotta wait on the issues.
Hey @langley-agm, I hope you're well.
I agree that lib files shouldn't be compiled, but they will be anyways. There are several reasons why:
- Cut http requests by bundling them into a single vendor file
- Reduce file size by deleting unused code-paths (tree-shaking)
- Increase browser compatibility by transpiling into es5
The angular-cli probably runs the TypeScript compiler with --allowjs on all lib files just to make sure everything's in a consistent format, and it probably picks up those TS files because of 2.0's changes. Whether this is a bug or not is debatable, you're free to open an issue regarding it.
I think it's fine. I think npm packages should separate their js from the ts.
I think having your source & output mixed together is worse, not to mention it's just messy. I think the way to go is to mimic how ng2 organizes their packages, since this is an ng2 library. Deploy as es6 with a umd-es5 bundle, and use the main, module & typings tags to to tell Webpack (or whatever middleware) where to find the appropriate entry points. That way, the client has the most control over how to use your libs. I learned a bit about ng2 production builds from this blog post.
You have no idea ahead of time what code-paths the client will call, for example, so you can't deliver a 'final' tree-shaken library. It'll still be processed by the client's toolchain and transformed however they need it.
It's depressing. But if it makes you feel better...
You're right to think this is ridiculous. My favorite episode of "Adventures in Angular" describes client-side web development as a toxic sewer of monkey-patches that you need Adderall to navigate. Every project is a dumpster fire, and every file might be processed additional times before it's deployed. Your lib is fair-game for tsc and other tools. After all, nothing's actually compiled until it hits the browser.
Just remember...
I'm not an idiot. I spent a lot of time thinking about this. I was hoping you'd actually look at how I solved the problem and give me some feedback, then I'd issue a pull request if you're happy with the design direction. At the very least, I was hoping this project would benefit by looking at some of the ways I solved problems.
Either way, I'll continue to use my little fork of this project and maybe add to it.
This project is interesting. 👍
Ha, edited the best part :)
Most heated "search for truth" I've witnessed so far!
Thanks guys!
It's a good edit, though. I want to move in a positive direction. :)
A lot of the refactoring I did in my forked version was just to preserve the idea of novelty sub-packages like angular2-logger/subsection. If you don't mind a breaking change, here's a two-line fix.
It'll require everyone to import from the root angular2-logger from now on, though. That's the trade-off.
I learned a lot by experimenting with this. 😄
Just to clarify from earlier, running tsc on js files with --allowjs will ensure they're in a specific target & module format. That's why you'd specifically re-compile your js libs with tsc.
In the blog post, he talks about how it's necessary to use es6 js when you run rollup, even though you want es5 in the end. The TypeScript compiler has to run twice in this case, and it has to process your libraries. First, tsc makes everything es6 before rollup (better static analysis for build-time) and then it's run again to make the final es5 output (better compatibility for run-time.)
I'm not sure if that part was clear when I explained earlier.
I just went through Angular2's webpack setup guide and this error does not happen even though I'm using "typescript": "^2.0.2",, like I mentioned before webpack should be targeting the already compiled .js files and should not compile ts files at all.
Now that I've seen that it's nothing to do with the structure or webpack, I'm going to fix this specific error so it doesn't hurt those using angular-cli, however I strongly suggest to take a closer look at it or even open an issue in their repo so they can narrow the root cause and once we find it, if there's something we have to do on our side we'll take a look at it, because compiling third party libraries already compiled will make your build process inefficient to say the least.
This is the guide I followed:
https://angular.io/docs/ts/latest/guide/webpack.html
And I had to do no extra configuration for the angular2-logger to work.
Thank you, @langley-agm.
FWIW, I'm working on a prototype just by myself, so I've been just adding that + to convert a string to a Level directly in the module.
I really didn't expect this seemingly minor issue to uncover such a deep flow.
In any way, thank you for the investigation and a great module!
Hello, I seem to be having this same issue using "angular2-logger": "0.4.5" and "typescript": "2.0.0". Any help on this is appreciated!
Example error message:
ERROR in [default] .......node_modules/angular2-logger/app/core/logger.ts:62:38
Type 'string' is not assignable to type 'Level'.
@ascreamingweas Yes, this entire thread is about this problem :)
You can do one of the following directly in the relevant line of the angular2-logger module.
These are obviously temporary hacks:
private _loadLevel = (): Level => +localStorage.getItem( this._storeAs );
or
private _loadLevel = (): any => localStorage.getItem( this._storeAs );
Yea @ascreamingweas ,
In short, it means your build process is compiling this third party library which is an overhead in your build process since the library is already compiled, the fact that you get this error means your build process can be highly improved in order to avoid already compiled third parties (not only this one, but any), getting compiled once again by your PC. If you follow the Quickstart Guide in Angular 2 for either SystemJS or Webpack you won't get this error.
If you don't care about this extra overhead in your project's build process you can leave it as is, I'll be commiting a fix for this error soon enough.
Thank you @vkniazeu @langley-agm for your help with this!!
Hi all, I've looked at the fix but I cant seem to get it to apply to my statement...
var _user: User = localStorage.getItem('user');
Does anyone know what I need to do?
Thanks!
Hi @bloobird ,
Your statement is not related to this fix, what are you trying to do and what are you expecting in the user var?