I have the following structure whereby I have common code used in a number of projects that itself contains other third party ember addons. I add these third party addons to the dependencies hash in package.json so they flow down to consumers. Therefore I don't have to install them in every consumer manually which would cause a maintenance headache when updating a single dependency.
common-code-addon
- third-party-ember-addon
myapp
- common-code-addon
The problem is that the included hook in index.js which might import bower dependencies such ass .css and .js code does not work from myapp. What is the recommended way to allow them to flow down properly?
Related
Good day,
I got my own package that I've installed into Sylius based on Sylius plugin-skeleton. The main class in /src folder of that plugin is called, but I need to work with other classes from /src folder. For example I got /src/Menu/RewriteMenu.php that I need to trigger method via services.yaml and I need to do this inside package - not to configure listener inside Sylius project. How can I achieve it? Thank you very much for response.
You can have a src/Resources/config/services.yaml file with your services declarations there.
You then need to import the configurations from the root configuration files. For example, to import your plugin's services, you can do this:
# config/packages/_sylius.yaml
imports:
...
- { resource: "#YourPluginName/Resources/config/services.yaml" }
In cases like this one, you can take a look at other Sylius plugins source code to see how they achieve things. But as a rule of thumb, anything that you customize in a root level basis, can be also done in a plugin moving the non-php stuff inside the src/Resources folder: configs (like services, serialization, validation, etc), templates, translations, assets, etc.
How do we use a babel plugin that is not already accepted in a babel repository? I had trouble finding this answer reading through the babel plugin documentation.
We are interested in writing a babel plugin for for...in loops to address a bug in ios9 (ios9 Safari miscalculating sum). Although we would be happy to contribute it to the babel community, I was also wondering if it doesn't get accepted or isn't ready for general consumption, how to start using and testing it locally.
It's possible to make use of custom babel plugins that you can host on git.
You can refer to https://github.com/jamiebuilds/babel-handbook/blob/master/translations/en/plugin-handbook.md for learning how you can develop and test your babel plugin locally.
Once you have developed the plugin, you can add a dependency for it in your project's package.json file.
Note that if you plan to make the plugin repository private, you'd have to create a personal access token (for Github) to allow npm to fetch repository contents. In that case, the example entry in your package.json file would be as follows:
"babel-plugin-transform-for-of-loop": "git+https://{token}:x-oauth-basic#github.com/username/babel-plugin-transform-for-of-loop"
Whatever package name that you pick for your plugin, you will need to add a reference for it in the .babelrc file. For this example, it would be as follows:
{
...
"plugins": [
"babel-plugin-transform-for-of-loop"
]
}
With that done, you should simply run npm install and your plugin would become active for your project.
When we generate a maven AEM project, how do we decide the archetype to use? What are the deciding factors and best practices for the same?
You can find the a baseline structure provided in Adobe-Marketing-Cloud space on Github - aem-project-archetype
This is a very basic structure to start with and provides you following modules -
Core : Core bundle (java code goes here)
it.launcher - Baseline bundle to support Integration Tests with AEM
it.test - Integrations tests
ui.apps - Module for your components,template etc code.
ui.content - Project sample/test content or may be actual content (actual content in codebase is not a good practice)
Important thing to know prior to deciding the structure for your project is -
Is the implementation for multiple brands or to be used across multiple projects
Is there a need of platform which provides the basic/core functionality/features to be extended by different implementations
What is the roadmap for the project
That said, a best practice is to separate interface and implementation into different modules. Most modules will have 3 sub-modules (api, core and package).
api: OSGi specification describes a modular system with separate api
bundle
core: An implementation bundle providing a service
package: Packaging 2 bundles to generate AEM content package.
There can also be packages which consists of contents without api/service. Such modules do not follow convention of osgi bundles, for example configuration, components, design etc.
In most of the our AEM implementations, the project was generated from the com.cqblueprints.archetypes:multi-module Maven Archetype and its folder structure was refactored according to AEM 6 Implementation Guidelines.
All modules created are to organize dependencies in better way and have clean separation of package deployment.
Number of modules can vary depending on the project, some common reusable modules as baseline may include -
1. build-settings
This folder can hold commonly used settings and scripts :
- CI server scripts/setting
- Maven's settings.xml
- Reusable bash profile specific to project etc.
2. Common Module
This will have [api,core and content sub-modules]. As name suggests this should have generic service or utility classes that do not belong to any module or can be used across all modules. Be extra careful and justify reason for adding classes in this module else as a malpractice everything ends up on common module.
3. UI Module
This will have [api (optional if you need OSGI services here),core and content sub-modules].
- The core module holds all your SlingModel, WCMUse extensions and
supporting Pojos.
- Content package to contain all your UI functionality related to components, templates. Its important to structure this module correctly so that addition of components, pages etc doesn't make it unmanageable.
We created following structure in the content module, /apps/<your_project>/ui
components : all components goes here. Further sub categorized as [content,global,scripts]
install
page : page components
templates : page templates
4. Configurations Module
This module to carry OSGI, Cloud Configurations and if implemented the /conf based implementations as well. Conf based implementation sample here
OSGI Configurations Module : Package module with all configurations as content.
Cloud Configuration Module : Package module with all configurations as content
5. Sling Error Handler Module
Any error handling content should reside here. Sample configuration has author mode display error stack and in publish mode it returns 404 response.
6. Designs Module
Any error handling content should reside here. Sample configruation has author mode display error stack and in publish mode it returns 404 response.
7. Content Module
Packages sample content and/or test content. In some implementations we chose to keep test content as separate module.
8. Complete Module
The is the package module that gets compiled at the last and combines all the packages generated in above modules into a single package for deployment to the server.
If your application has lot of business logic or processing you could add up more modules, for instance in couple of projects we have following additional modules as well -
Grunt/Gulp build
Services/Operations (for business layer)
Validations
Data Import
Incontainer tests
Incontainer test content
In addition to these we created a pom project that abstracts all the dependencies, configurations, plugins, profiles specific to AEM project and used that as a parent for the project POM. This cleaned up the project pom and allowed for reusability across projects for same client.
Sample parent.pom here
I've created a new foundation project using the foundation new myproject --libsass method.
Its just a simple static index.html (for the purpose of this question).
I've deployed it to a live server now, and I am wondering about the best way to structure this. I have omitted the node_modules & scss directories, and i'm left with the following:
bower_components/
css/
js/
index.html
bowerrc
bower.json
Gruntfile.js
humans.txt
package.json
README.md
bower_components is needed in its current form, unless I shuffle some files around, which is what I intend to do, but I'm checking if there is a better way of doing this, and that I haven't missed some magic terminal command to deploy to production.
As msturdy suggested in the comments, grunt is the way to go here. There are a lot of plugins out there, see a list on the official page.
If you want to have grunt "compile" your project into one specific folder which you can then for example push to a deployment server, you should do several things in grunt:
compile your scss
minify your javascript, that is making the files smaller, see jscompress for a demo of what it is. All your js-files from /bower_components which you include in your project should be in a vendor.js which is loaded first, and then a second js-file should contain your custom js from /js
save everything into a deployment folder.
(optional) automatically deploy to a server.
Take a look at these grunt tutorials for setting up your gruntfile.js, you'll want to have two tasks, one for just quickly compiling your scss, one for the whole deployment process:
grunt is not weird and hard
official tutorial
sitepoint tutorial
They show you how to do certain things and definitely how to write the gruntfile. Plugins you might want to use apart from your current libsass plugin are uglify and any plugin that lets you deploy your code via git, ftp or anything else. You can download all these plugins via npm by adding them to your package.json and doing npm install, refer to their websites for exact usage instruction.
everyone.
I am new to Go language and currently I am trying to understand the basics of building Go applications. I met the following problem.
For example, I am using other libraries in my project. I have them locally, on my computer, so my project works fine.
I am loading my code on github and another programmer download it. As I understand, my code won't work, because this programmer doesn't have the libraries I used.
So the question is: What is the best way to share my project with all libraries it has? Should I upload these libraries in the separate repositories? Then to use my project, people need to look inside the code to detect which libraries I am using to download them one by one?
For example, in Java there is such thing like Maven or Ant, which downloads all required dependencies. Is there any tools like this for Go?
Let's call the main file of my project main.go
And I am using my own library: mathutil.go
what is the best way to make this project run on other computers?
Go's dependencies work very much like using Maven or IVY transitive dependencies. When someone does "go get" of your package, anything you depend on will automatically download.
For example, in your source:
import "github.com/foo/bar"
go will automatically download that to your $GOPATH/src/github.com/foo/bar along with your code.
Assuming the third party libs you use are hosted in a public repo (ie: github) then people don't need to do anything.
If the libraries you used are not available on a public repo, you will need to post them somewhere assuming their licensing allows.
Take a look at golang.org/doc/code.html for more details