I'm trying to upgrade a very old version of Aurelia CLI project v0.24.0 to the current version v1.2.3. I've tried to follow the steps from this link from the docs but when I try to run it I receive this error:
So my question is what is the best approach to upgrade it from such an old version to the newest one?
Just a screenshot of error is too little info to give proper advice on. And between the currently latest version of v1.2.3 and v0.24.0 (Jan, 2017) there's roughly 3 years. Fun part is, you'd be amazed at relatively how little Aurelia core itself has changed. Simply because a lot remained stable.
Most impactful changes will be in either:
aurelia_project folder, with the build and config routines
bundler config (system.js, webpack, requirejs - whichever you've used)
That being said, this does not necessarily mean that your dependencies have also remained stable in those past three years. Especially in Javascript world. To accommodate for this, I would suggest:
Create a blank, new project with the latest Aurelia CLI
Copy/paste over the /src folder from your old project to your new one
Take in consideration specifics, like package.json from your old project and migrate them by hand (reinstalling) in your new project
Again, try to keep your bundler similar and you will have relatively little changes. But if you choose you want to migrate from System.Js to Webpack, it'll be a bit more hassle. But arguably, rewarding in the end if your project needs to be kept alive for a longer while.
Considering the age of your old project, restarting with a clean setup and config is what I would consider to be "the best way" to retouch only the necessities.
Related
The answer seems like 'no' but I wanted to check with colleagues here.
We provide an npm package for our own sites as well as some 3rd party sites.
There's a fairly heavy and old homegrown npm package that we also have in our package.
We don't need that package any longer on our sites but the 3rd party sites do.
We also have no way of controlling the code on those 3rd party sites so we need to keep the deployed bundle name and location the same for them.
Is there a way to publish a version of our package first without the extra package for us and then a version with it for the third parties from the same repository?
ourpackage-new.js (without the dependency)
ourpackage.js (with the dependency)
I had some success with a new package json in a subdirectory. I would create a new package and the original package via a command in gitlab.yaml to cd into that directory and npm publish there after the first one. This requires copying some dependency files down there as well which would mean if one version was updated, we'd need to remember to update the copy. Not a situation we'd want.
Even if we created a 2nd repository for the change just for us, we'd still need to update 2 repositories every time we had a new change to deploy.
Checked into Aliasing as well, we wouldn't be planning to import a new version and an old version though, more like sister versions.
In any case, thanks for the input and thoughts. I realize Npm was prob not made for this type of situation. If I remember right, I could do this with Gulp years ago, but I haven't even thought about Gulp in so long :) And then, I'd have to deploy manually via an FTP program ... wow, those were days.
Thanks again!
Some time after the release of Elm19 I published a library, which I needed for an Elm18 code base: thought2/elm-wikimedia-commons.
This worked well, it's listed in the community driven Elm18 package database: https://dmy.github.io/elm-0.18-packages/, can be installed and all good. Except the fact that the documentation is not shown in the package details, but that I heard is a known bug there. (But still I think this is very bad)
But the main problem is now, how to migrate the library to Elm 19: The actual migration steps are done and live in the master branch of the repo: http://github.com/thought2/elm-wikimedia-commons
The Elm18 versions proceeded to 1.1.0 in the meanwhile and after the migration there had to be done an API change, so I'd assume the latest version to become 2.0.0. If I add this to elm.json, the command elm publish tells me that this would be the first version and I should change this. Which is not right.
After a bit of research, I found out that the package (among other 18 ones that have been published in the same time period) is not listed in this json: https://package.elm-lang.org/all-packages This should contain all packages regardless of versions.
Any ideas what to do? This is really blocking my development, as I'm stuck in both lands now: 18 and 19. Would appreciate a lot if someone has some hints or solutions for me!
You shouldn't need to mess with the version number specified in elm.json.
If you set it back to the version of the package that is already published and run elm bump the elm program will look at the changes you've made to the package's API and set the new version accordingly.
Looking at https://github.com/thought2/elm-wikimedia-commons it doesn't look like any of your upgrade changes were breaking changes to your package API so the version won't be a 2.x.x, it will be a 1.x.x.
You'll need to remove the 2.0.0 git tag as well and instead add a tag for the version that elm bump tells you that your package is.
I started my project with a template:
react-native init myApp --templateez-devs
The template has upgraded and I would like to know if there is a way to upgrade my project without be manually.
tl;dr
In a word, no. You'll have to do it manually.
Templates
The templating system is quite dumb it basically creates a new react-native project and then copies the files that are included in the template and then installs the dependencies that have been listed.
As you will undoubtably updated files that were included in the original template, you wouldn't want to just install it over your existing project and hope for the best. That would cause you lots of problems. You may also have installed dependencies that require linking with native code, the template wouldn't specifically know about these changes.
Ways to upgrade
So how can you update to the new template? Well it really depends on what you have done to the project. Unfortunately there is not going to be an easy way to do it.
To see what the major changes are between the templates I would look at the files included in the release that you are currently using, and the release that you plan to use and create a diff this can be done using the following command
diff -ur b a > ba.diff
where a and b are the directories that you are comparing.
Unfortunately the template that you are using doesn't create releases on their github https://github.com/maykonmichel/react-native-template-ez-devs/releases
You could attempt to download them off of their npm page https://www.npmjs.com/package/react-native-template-ez-devs .
Ultimately you can compare the changes on their github by looking at the commit history, you could look at the changelog if it existed, you can also look at the dependency versions that they are using and see if they have differed from the ones that you have used.
You can use github to do your compare
Here is an example of the comparison between the most recent commit and one from a few days before.
https://github.com/maykonmichel/react-native-template-ez-devs/compare/f4ffa06..04a1b8c
Is there a tutorial somewhere that shows you how to install & build Aurelia MANUALLY in Visual Studio 2017?
Why do this?
Ideally I'd like to use bundleconfig.json for as much as I can and
use gulp for those things I can't do in bundleconfig.json.
I'll learn every aspect of the build/bundle/package process as possible instead of having a tool set that up for me. (Makes things
easier to troubleshoot if I know how it is all setup.)
I won't be dependent on CLIs and packages that are not kept up to date. (Several that I've looked at are based on VS 2017 RCs).
I've tried several CLIs and "skeleton" projects but they all have their issues. Some haven't been updated to use the latest csproj.
Aurelia CLI: Project/Folder structure doesn't mirror any standard way of building SPAs that I've seen. Also doesn't mirror what you get when using Aurelia's own "Skeleton Project."
dotnew new spa templates: Though the most promising it's typescript only and not ES6. (Maybe there is a way to switch it easily?)
Aurelia's Skeleton Projects It adds dependencies that I do not need. It also does not work out of the box.
So here is what I've determined since originally writing this question.
My original thoughts with lessons learned:
Why do this?
Ideally I'd like to use bundleconfig.json for as much as I can and
use gulp for those things I can't do in bundleconfig.json.
Answer: I was only doing this because I was trying to embed Aurelia inside of a web api project in Visual Studio. I recommend you don't do this and instead keep it as a separate project. (Separation of concerns)
I'll learn every aspect of the build/bundle/package process as possible
instead of having a tool set that up for me. (Makes things easier to
troubleshoot if I know how it is all setup.)
Answer: Though building from scratch would help me learn about this more it isn't a major roadblock. I was just inexperienced with more modern UI frameworks and their corresponding build processes. (RTFM)
I won't be dependent on CLIs and packages that are not kept up to date. (Several that I've looked at are based on VS 2017 RCs).
Answer: - That happens no matter what route you go. You can wait for a library to mature more if this is a big concern.
The bottom line is my question was based on some incorrect thinking. If you are trying to go this route you really need to ask yourself why and determine if it is worth it. To me it was not. Just go with what works, learn and move on. Oh and don't resist Typescript!
npm install aurelia-cli#0.30.1 --global
create new vs solution in 2017 (ASP.NET Core Web App)
with command prompt, cd into the solution root dir (not wwwroot)
au new --here
select RequireJS or SystemJS (my personal preference)
select option 2, asp.net core
select the remaining options.
Run f5 in VS2017.
Just getting ready to upgrade from 5.1 to 6.3. We have never performed an upgrade before.
About the upgrade path: When installing the updates, do I need to install the hotfixes, or just the major releases? (My gut says only major releases).
I found the documentation here:
http://www.sitefinity.com/documentation/documentationarticles/upgrading-you-sitefinity-5.1-project-to-the-latest-version
Is this documentation enough to make a smooth upgrade?
Yeah, just follow the documentation in the link you posted.
My process is to take full backups of the site files and database then perform the upgrade locally. Do the first step in the upgrade path then run through the site to test, back end and front end, then run the next step in the upgrade, and so on. I suppose if you want to be extra careful you could take additional backups between each upgrade step but that's probably overkill.
When making the web.config changes, there is an option to have Project Manager merge them for you but I end up just using Beyond Compare to compare the _EmptyProject folder in the extracted Project Manger files to my local files and do the web.config changes through a file compare. It cuts down on the differences in files from upgrade to upgrade and shows you whats been changed. The _EmptyProject folder is essentially the vanilla Sitefinty site files for that version.
Once the site is fully upgraded locally, I just publish the site in Visual Studio, copy the files over to the live site and overwrite the live database with a backup of my locally upgraded database.
Hope that helps.
I have upgraded Sitefinity 5.1 to 6.0, on a website which is in production (which included going through a couple of steps for the versions between).
I just followed the guidelines, and it went fine.
Now there are a couple of things you need to be aware of :
Source control
If your Sitefinity solution is on "Source Control", you should create a new duplicate of your solution, and disconnect this one(newly created) from "Source Control" before starting the upgrade. And of course you do the upgrade on the solution which is not in Source Control. Because you will probably have a lot of dll's to integrate, and if you have the project manager, your sitefinity project will run correctly, even though the new dll's aren't properly integrated in your solution and possibly "source control".
Unexpected behaviours of previously working elements
Secondly, I didn't test the frontend and backend during the different steps (Sitefinity versions within upgrade), but I tested everything once my solution had reached the last Sitefinity version. I thought I had checked everything, but it wasn't the case, and some of my custom Widgets didn't work properly on the latest version of Sitefinity. Next time I'll go more in detail on all custom parts, since from a working version of Sitefinity, you can end up with a newer version that breaks some behaviours. If you notice this, you might better wait a bit more for a fix, or the next release which might fix the problems.
Outside access to website during upgrade.
Furthermore, once you need to do the upgrade on the production database/website, the website shouldn't be accessed by people, since the upgrade of database might take some time.
Time needed for upgrading everything
One more thing I would like to add, it takes time to perform upgrade of several versions.
The first time I upgraded (I needed to go through 2 versions), and having to upgrade locally, to a development database, deploy the website on developement environment, then make it again on test. I took about 4 hours before everything was fully working. Make sure you have enough time, because it can be more tricky if you need to stop everything then come back to it.