Install as silverstripe-mymodule or just mymodule...

[Martimiz]

Hi all,

Some modules save as silverstripe-mymodule, some as mymodule. What would be the preferred way, according to your opinion? The docs suggest to use 'installername' to add a custom name, but some people feel that the silverstripe- prefix makes a module better recognizable as a module.

When using composer, just changing the foldername manually doesn't seem to be an option, because composer update seems to just recreate the module, leaving you with two, which you definitely don't want.

I'm not sure what other options there are, I see silverstripe-framework being installed as framework, without an installername defined in composer.json, and I don't know how :) Or are there clientside options to override the module's composerdefined path? I am officially confused...

[Loz Calver]

The “silverstripe-” prefix is probably just going to be personal preference, I don’t usually bother adding it to modules myself.

I have used it before, though - for example my module named “kinglozzer/silverstripe-columnedlist”. I used Composer’s “installer-name” option like you suggested to install it in a directory named “columnedlist” instead of “silverstripe-columnedlist”. I always try to set up my modules so that it doesn’t matter what the directory name is - so people can install via composer or by downloading from Github.

When using composer, just changing the foldername manually doesn't seem to be an option, because composer update seems to just recreate the module, leaving you with two, which you definitely don't want.

If you’re using Composer, you shouldn’t need to change the directory name - adding the installer-name option to an already existing module should rename the directory (I haven’t tested that, but it’d be a bug if it doesn’t!).

I see silverstripe-framework being installed as framework, without an installername defined in composer.json, and I don't know how 

I believe that’s because the full name is “silverstripe/framework” (not “silverstripe-framework”), so the package name is just “framework”.

Loz

[Daniel Hensby]

Hi Martimiz,

In terms of prefixed module folder names, I have no opinion - whatever you feel is better. I'd probably lean on the side of not having a prefix, but given I've never defined the intsallername property on a project of mine, it clearly didn't appear to be worth the effort for me.

The framework installs into framework due to the silverstripe-module installer that composer uses which has a special case for framework - really, it should use installername, but I'll give the benefit of the doubt that when the installer was written, it didn't support that property OR there's some kind of issue with having 2.x install into sapphire and 3.x install into framework.

Dan

[Martimiz]

Thanks guys,

>>If you’re using Composer, you shouldn’t need to change the directory name - adding
>>the installer-name option to an already existing module should rename the directory
>>(I haven’t tested that, but it’d be a bug if it doesn’t!).

Adding the installername to the module's composer.json that is already on your website unfortunately isn't going to work. 

Basically (unless someone knows more): if you want to change a module's directoryname, you cannot update using composer. And even if you forgo composer, the module still needs to be directory-independent, which not all of them are. And I haven't found anything 'official SilverStripe preferred' so it's probably just up to the developer... :)

Martine

[Florian Thoma]

Hi guys,

I definitely prefer the module names without prefix and usage of the composer installer-name property.

IMO it just makes the installation cleaner and more consistent when using modules from silverstripe (like cms, blog, etc) and other parties.

Flo

[Uncle Cheese]

Major benefit for me is that you can bulk exclude all the modules in your .gitignore:

silverstripe-*

[Patrick Nelson]

Would it be feasible to setup a sub directory like "modules" and add a little extra code to scan through that directory similar to how the root site directory is scanned in order to facilitate modular functionality (I.e. Looking for code directories and config files, etc)?

That way it doesn't matter what the author chose to name the module (notwithstanding collisions obviously) and the ignore and grouping problem is easily solved. Also, easy to migrate old to new functionality. We already use a customized composer installer which can possibly be updated to ease the migration possibly.

Sent from my iPad

> On Apr 11, 2015, at 9:23 PM, Uncle Cheese <aa...@silverstripe.com> wrote:
>
> Major benefit for me is that you can bulk exclude all the modules in your .gitignore:
>
> silverstripe-*
>

> --
> You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-d...@googlegroups.com.
> To post to this group, send email to silverst...@googlegroups.com.
> Visit this group at http://groups.google.com/group/silverstripe-dev.
> For more options, visit https://groups.google.com/d/optout.

[Aaron Carlino]

Andrew Short talked extensively about this, and it was part of his work for the Google Summer of Code in 2012. I’m sure there’s heaps written about it, probably in here, but the one thing that comes to mind is the podcast we did with him. http://silverscoop.org/home/episode/5

Aaron Carlino | SilverStripe Evangelist
SilverStripe
http://silverstripe.com/

Skype: aaroncarlino.silverstripe

You received this message because you are subscribed to a topic in the Google Groups "SilverStripe Core Development" group.

To unsubscribe from this topic, visit https://groups.google.com/d/topic/silverstripe-dev/MMZkS76s19k/unsubscribe.

To unsubscribe from this group and all its topics, send an email to silverstripe-d...@googlegroups.com.

[Florian Thoma]

Major benefit for me is that you can bulk exclude all the modules in your .gitignore:
silverstripe-*

Yep, that's true. But you can also use negative exclusion in the .gitignore file:

# ignore everything...

/*

# ...but

!/.gitignore
!/composer.json
!/composer.lock

!/mysite
!/themes

!/assets
/assets/*
!assets/.htaccess
!assets/web.config

[Aaron Carlino]

Yeah, that’s what most of my .gitignore’s look like, but a lot of people prefer something more explicit.

Aaron Carlino | SilverStripe Evangelist
SilverStripe
http://silverstripe.com/

Skype: aaroncarlino.silverstripe

[Stevie Mayhew]

You may be interested in a cool module from Guru Digital:

https://github.com/guru-digital/SSAutoGitIgnore

Very handy.

    "require-dev": {

        "gdmedia/ss-auto-git-ignore": "~0.0.3"

    },

    "scripts": {

        "post-update-cmd": "GDM\\SSAutoGitIgnore\\UpdateScript::Go",

    },