Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Problem/Motivation
When installing the core JS dependencies there is a core/node_modules
folder, which is not covered by our .gitignore.
Steps to reproduce:
- Install yarn
- cd /core
- "yarn install"
Proposed resolution
An entry to example.gitignore for core/node_modules
. This is equivalent to ignoring the vendor directory for dependencies managed by composer.
Remaining tasks
User interface changes
None
API changes
None
Data model changes
None
Comment | File | Size | Author |
---|---|---|---|
#18 | 2859663-18.patch | 434 bytes | alexpott |
#14 | 2859663-14.patch | 350 bytes | alexpott |
#13 | 2859663-13.patch | 347 bytes | alexpott |
#7 | gitignore-node-modules-2859663-6.patch | 291 bytes | marncz |
#4 | gitignore-example-node-modules-2859663-4.patch | 335 bytes | marncz |
Comments
Comment #2
ritzz CreditAttribution: ritzz at Iksula commentedI am working on this.
Comment #3
ritzz CreditAttribution: ritzz at Iksula commentedComment #4
marncz CreditAttribution: marncz commentedComment #5
marncz CreditAttribution: marncz commentedComment #6
cilefen CreditAttribution: cilefen commentedYarns docs recommend checking in yarn.lock.
Comment #7
marncz CreditAttribution: marncz commented@cilefen
thanks! updated the patch
Comment #8
cilefen CreditAttribution: cilefen commentedLet's see what @dawehner thinks about this. He doesn't do things for no reason, so usually there is a reason.
Comment #9
dawehnerFair point @cilefen it is similar to our
composer.lock
files.I honestly don't know anymore what I have been thinking. I cannot agree more. Too bad we don't ship with one at the moment :)
Comment #10
dawehneroh right, this is what annoyed me. I used yarn to install the dependencies and then ended up with a yarn.lock file laying around.
Comment #11
lauriiiDrupal core has only development JavaScript dependencies. These are only installed in a core development setup. Therefore this setup is not needed in most environments. Should we just add this as a commented line and say that you can uncomment this if you need it?
We should at least improve the documentation about what is this actually needed for so that it is easier for people to see what is each of the ignores intended for.
Comment #12
dawehnerFor me there is not much difference to the
core/phpcs.xml
andcore/phpunit.xml
filesComment #13
alexpottI agree with @dawehner we should add this to the example.gitignore If you are doing core javascript development then not having this is going to be a bugbear. If you are not doing core javascript development you are not going to notice.
To see what happens:
1. get npm or yarn
2. cd /core
3. "yarn install" or "npm install"
You'll end up with a core/node_modules directory that you do want to check in. These dependencies are going to be used to build Drupal's js.
I also agree with @lauriii that we can improve the comment.
Rather than this being like phpcs.xml this is most like the exclusion of the vendor directory - and we definitely don't want to have a repeat of committing something like that. Moving to the documentation component because this is only an example file and has no run-time effect.
Comment #14
alexpottWrapping...
Comment #15
dawehnerThank you @alexpott!
I personally think that creating a follow up to simply group all the "development" related files together could be helpful.
Comment #16
alexpottUpdated the IS
Comment #17
alexpottCreated #2861497: Check in yarn.lock and recommend usage of yarn to discuss the yarn.lock issue.
Comment #18
alexpott@lauriii pointed out that there is a line that says
So we need to be above that line. Putting it next to vendor cause it is about the same stuff.
Comment #19
dawehnerI believe if someone edits a
.gitignore
file they kinda know already how it works.Comment #21
lauriiiThanks everyone! I've committed fa8889e and pushed to 8.4.x.
As a documentation issue, this could be considered to be committed for 8.3.x as well.
Comment #22
xjmIf the line were commented out, then I'd call it documentation, but in this case it is an actual uncommented line of the example gitignore. If people are merging this into their gitignores then it could change behaviors. I think it's fine to make this change in 8.4.x only; it does not prevent anyone from adding it to their gitignores if they need to.
Thanks @lauriii!
Comment #23
alexpottThere's another way of looking at this. We are explicit at telling people not to make changes to anything inside ./core but building the yet-to-be-used tools to make core's js we need to put the dependencies somewhere. We really don't want to put these things outside ./core so ./core/node_modules makes sense but it would never make sense to commit ./core/node_modules and someone doing that is in for quite a few difficulties. In my opinion, not having this in your .gitignore is a bug.
As we're yet to use ES6 and these build tools no one is running into this problem. All this said, we're probably not going to move to ES6 on the 8.3.x branch. However I would think that putting this in 8.3.x is sensible because we don't want people setting up a Drupal development environment in 8.3.0 and them not having this and then revisiting their gitingore in 8.4.x. If someone is at all affected by this then they are using Drupal in a completely unsupported way - and even so adding something to gitgnore won't remove their commits anyway.
Plus we really need to update https://www.drupal.org/documentation/git/configure#gitignore since that doesn't contain the necessary info about this or vendor for Drupal 8.
Comment #24
droplet CreditAttribution: droplet commentedOr put a
core/.gitignore
?Comment #25
alexpott@droplet that's an excellent idea - let's file another issue to do that.
Comment #27
alexpottCreated #2867290: Introduce a core/.gitignore as a followup based on #24