Develop Reference

Angular application won't run - Cannot read properties of undefined (reading 'write')

I have an angular application I haven't touched in a while. I haven't made any changes since the last time it was working. Now I need to modify a few things. But the application won't serve locally so I can't make the changes. I don't understand what's wrong.
The npm install worked just fine and I don't have any code errors preventing it from running. I get the following error message when trying ng serve, but it seem extremely unhelpful. Any ideas?

Unfortunately without an exact reproduction of your project this will be really hard to pin point, but looking at what is given in the screen shot and prior experience with similar issues, I think this could be an issue with your package.json. Newer versions of node and npm look for the carets symbol (^) in both your package.json and the installed modules' package.json. When found, it will install newer versions of the package without error. Then when you go to run the project, the typings will break and Angular will refuse to compile and you get errors like these.
I would recommend removing all carets in older Angular projects to prevent this from happening as it is common occurence even when upgrading from more modern versions (I had this happen to me when upgrading from Angular 13 to Angular 14). However, with Angular 1.7/AngularJS not being supported anymore, I would recommend that you look into upgrading or rewriting the project in a modern version of Angular or another modern framework that fits the projects needs.

Does Aurelia-Fetch have a dependency on whatwg-fetch?

I am trying to upgrade my Aurelia project from a beta version to the March version.
One of the errors I am getting is:
Cannot find name 'Request'.
Googling this brings up this issue on GitHub: https://github.com/aurelia/fetch-client/issues/65
This issue says that the "fix" is to install the typescript definitions for whatwg-fetch. When I do install those typescript definitions, the error goes away.
But does that mean I need whatwg-fetch too? (Looking in my node_modules folder, whatwg-fetch is not installed.)

aurelia-fetch-client wraps the Fetch API. wahtwg-fetch is a Fetch polyfill, so it wouldn't make sense for the fetch client to depend on the polyfill. Furthermore, which polyfill you will use changed depending on which module loader you are using.
JSPM/SystemJS based apps use the fetch polyfill from GitHub, while most other module loaders use whatwg-fetch.
So yes, you will need to install whatwg-fetch, but there's a good reason for why the aurelia-fetch-client doesn't have a dependency on it.

how to use a fork of a meteor package when the original package is a dependency

Context
I'm using the aldeed:autoform package and found a couple bugs & filed PR for it(https://github.com/aldeed/meteor-autoform).
Aldeed being the only maintainer of a lot of popular packages ends up being the bottleneck for merging PR & following up with issues.
My solution was to fork his project & published my fork on atmosphere.
Naively, i just removed his package meteor remove aldeed:autoform and tried to add mine: meteor add metakungfu:autoform
When i load my app, i get the following error:
Package['aldeed:autoform'] returns the expected object, even though i removed the package.
For sake of completeness, i do use a bunch of other packages that depends on aldeed:autoform and my guess is that this is the reason why aldeed:autoform package is still present.
Questions:
What's the right way to use a fork of a package, when that package is dependency of other packages?
Is this the right way to solve my problem?

I've end up using mgp to manage the packages.
In order to solve my problem, i had to do two things:
First, add a git-packages.json in the root of your project that looks like this:
➜ cat git-packages.json
{
"aldeed:autoform": {
"git": "git#github.com:gregory/meteor-autoform.git",
"branch": "dev"
}
}
This will work locally, but if you deploy to heroku, the buildpack will need to install mgp & install the dependencies.
I just opened a PR to fix this

Fork all the dependencies and make them point to your fork.

Instead of publishing your own version of aldeed:autoform onto Atmosphere, you should rather use it as a local package, keeping its name intact. Meteor will look first for your local packages, before trying to fetch from Atmosphere.
That way, all your other packages that depend on it will use your local version.
To do that, see: Why does Meteor's aldeed/meteor-tabular package get stuck processing and never render a result?
Reference: Meteor Guide > Build > Writing Atmosphere Packages > Overriding packages with a local version

(webpack) library version conflicts, npm vs bower

Getting started with webpack, and while not explicitly stated, a lot of examples and starter kits use NPM over Bower for managing their front-end libraries. Further, recent articles suggest we don't need Bower any more. Maybe I'm using the wrong workflow, but I don't see how NPM can fully replace Bower when you're using libraries with shared dependencies.
Consider a project that uses jQuery and two jquery plugins. The first requires 2.2.0 and the other requires 2.0.3.
When webpack creates the bundle, two versions of jquery exist!?! Yes, the DedupePlugin can be used to remove the duplicates, but I can't find any documentation regarding which version it keeps. Seems like it just keeps the first one it encounters. Therefore, if I want to force a specific version, I need to npm install jquery and add a resolve.alias.
On the other hand, with Bower, I know exactly which version is being bundled. And should a conflict arise, it tells me. I can investigate the conflict and specify the appropriate version.
What am I missing? How are you using Webpack with front-end libraries? What is your workflow?

Using latest version of TypeScript Definition with older JavaScript libraries

I am using older version of AngularJS - v1.3. Looking out for corresponding type-script definition files.
Will latest type-script definition be compatible with older library
version?
https://www.nuget.org/packages/angularjs.TypeScript.DefinitelyTyped/
Its difficult to find mappings between Angular JS type-script definitions file version & Angular JS library version. Can we just go ahead with latest version of typescript definition available.
EDIT: I had to compare two nuget repositories & took a version where angular.d.ts comment changed from // Type definitions for Angular JS 1.3+ to // Type definitions for Angular JS 1.4+

Usually you can search for previous versions' definitions by running the following command with tsd:
tsd query angular -v all
Then install the specific version you want (ex. tsd install angular -v 1.0.0).
There's a problem though. For some reason there seems to be only two other versions of angular available:
- angularjs / angular
- angularjs / angular-v1.0.0
- angularjs / angular-v1.2.0
For that reason, I would suggest to take a look at the commit history of angular.d.ts and find the last definition file before it switched from 1.3 to 1.4. Knowing when Angular 1.4 was released helps.
By doing that, you will find this definition file for 1.3.

Use the ref attribute to specify the exact type definition file version, which corresponds to the branch on git. In your case you can use the below steps.
Add the required tsd dependencies using
tsd install angular --save
The save step will create atsd.json file with below structure:
{
"version": "v4",
"repo": "borisyankov/DefinitelyTyped",
"ref": "master",
"path": "typings",
"bundle": "typings/tsd.d.ts",
"installed": {
"angularjs/angular.d.ts": {
"commit": "77ec1408257c677f8fd8d6798ebaf6bd87c11b9d"
}
}
}
Update the ref attribute to required angular type definition version. In your case most probably it should be 1.3.0
Run tsd install again to download the required type definitions

What I have done is a bit like taking the long way and isn't exactly your scenario, but it worked for me and hopefully people in my situation will land here...
In my scenario I was ripping out NuGet as the typescript definition manager and replacing it with tsd and I needed a specific version of the lodash typescript definition (0.4.1) but tsd was installing the most recent version. Since versioning the way bower does it isn't yet supported upon install and tsd uses commit hashes to keep track of what version you're on, I used nuget to find the version I wanted:
then replaced the "commit" hash in tsd.json with the git commit listed in the Description:
It was a little painful because I had to type the hash in manually but it ensured that I had the version that I needed.