1

I'm trying to migrate my app from using Sencha Cmd to the newer Node/npm way that Ext JS applications are created, and I'm using this guide as my reference.

What I'm confused on is how custom packages are handled. I currently have a slew of "remote" packages that I built with Sencha Cmd (they were originally generated using this guide). I put remote in quotes because they're built on my machine, put in the bin/Sencha/Cmd/repo dir, and then Sencha Cmd knew to look for them on my local machine when I put them in the requires property of app.json. Now that everything is hosted on npm, it seems like maybe this connection is sort of lost, unless there's something about npm that I'm not understanding. And to be clear, we do not want to host our packages on any npm server... if anything, we'd host it ourselves.

Has anyone had any experience with a migration process like this yet?

incutonez
  • 3,241
  • 9
  • 43
  • 92

1 Answers1

2

The crux of this issue has to do with two separate installations of Sencha Cmd. With OpenTooling, the Sencha Cmd binary is packaged into a node module, residing node_modules/@sencha/cmd. When using the npm build scripts, or prepending Sencha Cmd build commands with npx, the Sencha Cmd installation inside node_modules will be used.

Before the migration, your Sencha Cmd installation was likely in your user home bin directory (default location). A quick perusal of this installation directory should reveal the sencha.cfg or .sencha configurations that contain information about your original Sencha Cmd installation - what is particularly helpful here is the information about this installations repo setup. If you did a sencha repo list you'd likely see the Sencha Cmd remote repo (Sencha's CDN), and in your case you would see your local repo along with the catalog.json and other metadata about the repo and the packages it contains. If you were to run the sencha repo list command against your OpenTooling installation of Sencha Cmd, you wouldn't see the same information.

These two installations, and the repos (and packages) they contain, are different and need to be reconciled. Unfortunately, this is not a part of the migration tool - but I believe it could / should be.

To setup the repo in your OpenTooling installation of Sencha Cmd, use sencha repo sync. This should automatically add a .sencha configuration directory and a repo directory if they don't automatically exist. It is inside this installation's repo your existing Sencha Cmd packages will need to be published/deployed/installed/etc., using the same commands (but with npx prepended) you used to setup the original repo. Once the packages exist inside the node_modules installation of Cmd, the standard build process npm start should be able to locate your packages.

Jordan Nelson
  • 21
  • 2
  • I've actually made quite a bit of headway on this... I have changed my app to be open tooling, but I'm still relying on Sencha Cmd to build my packages locally, which stores it in the global install of Sencha Cmd from npm... on Windows, this is in `AppData\Roaming\npm\node_modules\@sencha\cmd\repo\pkgs`. Because of this, in my app, it still looks at this repo when pulling packages. However, there's a bug in `sencha app refresh --packages`, and I had Sencha Support create a ticket for it. What I do is delete the package dir, and just run `npm start` which redownloads the missing packages. – incutonez Jun 24 '20 at 02:45
  • But yes, eventually, I think I will be posting my packages to something like Azure Packages, and I'll be using that to download the packages, which should get me off of having to use Sencha Cmd for anything, really. I know it's still used under the hood in the build process, but I won't be using it directly. – incutonez Jun 24 '20 at 02:47