Every update overwrites:
packages.jsondev/tools/grunt/configs/themes.jsCould be possible to rename them to something like packages.json.sample and themes.js.sample?
I agree.
Fortunately packages.json.sample is already available in Magento 2.1.0-rc1, see this commit: https://github.com/magento/magento2/commit/9ba77d903d173a134ef4c5b1f9de0d3f4d73d47d
The themes.js file remains unchanged for now. Hopefully that one will get renamed too.
I've just submitted a pull request for theme.js
馃憤
Pinging @xcomSteveJohnson as these changes will require the documentation about npm & grunt to be updated (http://devdocs.magento.com/guides/v2.0/frontend-dev-guide/css-topics/css_debug.html#grunt_prereq).
@hostep acknowledged, thanks!
Hi @slackerzz ,
2.0 --> 2.1 ? Or patch releases 2.0.1 --> 2.0.5?Thanks.
Hi @guz-anton,
themes.js _both_ kind of update replace this file with a fresh copy from the repodev/tools/grunt/configs/themes.js, but every magento update (minor, major or whatever) overwrites this file so every time you have to declare it again and again. It's not so funny and since this is a configuration file i think you could rename it to themes.js.sample and say in the docs to rename it to themes.js to use grunt.Ok. I got it. We are looking for solution.
Currently possible ways to solve task are:
theme.js to theme.js.sampletheme.js.sample to theme.js back.theme.local.js as fallback with local themes listMagento/luma and Magento/blank themes also. That is redundant.Maybe you have any ideas?
I've submitted a pull request following the first solution more than a month ago.
Yes, it's one more step for developers, but only once. If Magento is really moving to sass and gulp maybe it doesn't make sense to invest time to modify grunt tasks or introduce config files fallback.
Yeah, good reason. If we choose first one - we will process your PR ;-)
@guz-anton: since you already decided on the first solution for Gruntfile.js and packages.json in commit https://github.com/magento/magento2/commit/9ba77d903d173a134ef4c5b1f9de0d3f4d73d47d, it makes sense to use the first solution for themes.js as well I think.
Just a notice: internal ticket MAGETWO-55345 has been created.
Hi @slackerzz ,
Great thanks for your contribution in Magento and bugreporting. Your issue produce set of investigation and improvement in development process.
From 2.1 we already has packages.json.sample as packages.json.sample .
From now you have ability to place local
dev/tools/grunt/configs/themes.loc.js config file.
See implementation for more details.
@guz-anton i've just upgraded from 2.1.1 to 2.1.2 and my themes.js just got overwritten again....
when do you think will be available themes.loc.js config file?
@slackerzz
This improvement was delivered to current development branch - develop. It will available under the 2.2.0 version.
2.2.0 will be released within this year?
Hi,
May I ask why is this issue closed? The root problem is far from resolved, you just made a 'hack' for one mentioned file? I understand that here only one issue is mentioned, but other issues are being marked as closed/duplicate on behalf of this one, while they are still valid points.
And please do not tell me this is a feature, this is a bug that is heavily impacting development workflow. We can not predict what will be added in next release, and if by any chance this overlaps with my naming, my code will be overwritten.
For an example, you can not edit pub/index.php or the pub/.htaccess. Or any other file that was made by the composer in the first place outside the vendor folder. These files are not part of the framework/library or whatever, they are part of my application and should not be modified by composer install and composer update commands.
Regards,
Stjepan
For those being plagued by this issue, You can disable this feature by setting the following in the composer.json:
"extra": {
"magento-deploystrategy": "none"
}
This will update the magento composer installer code to not copy everything over on install.
Most helpful comment
Hi,
May I ask why is this issue closed? The root problem is far from resolved, you just made a 'hack' for one mentioned file? I understand that here only one issue is mentioned, but other issues are being marked as closed/duplicate on behalf of this one, while they are still valid points.
And please do not tell me this is a feature, this is a bug that is heavily impacting development workflow. We can not predict what will be added in next release, and if by any chance this overlaps with my naming, my code will be overwritten.
For an example, you can not edit
pub/index.phpor thepub/.htaccess. Or any other file that was made by the composer in the first place outside the vendor folder. These files are not part of the framework/library or whatever, they are part of my application and should not be modified bycomposer installandcomposer updatecommands.Regards,
Stjepan