It is said that Mojito can use JSON or YML as the application.json (the config file), but I haven't seen YML examples around?
For example, how to convert:
[
{
"settings": [ "master" ],
"specs": {
"hello" : {
"type" : "HelloWorldMojit"
}
}
}
]
to a YML file?
Also, when we use
$ mojito create app Hello
can't we specify that we want YML files as the default (instead of JSON files)?
Details:
I used npm's yamljs to convert the file to:
-
settings: [master]
specs: { hello: { type: HelloWorldMojit } }
and it doesn't work. And I edited it to
-
settings: [master]
specs:
hello:
type:
HelloWorldMojit
It won't work either. The server can start, but when the homepage was accessed, the error is:
error: (outputhandler.server): { [Error: Cannot expand instance [hello],
or instance.controller is undefined] code: 500 }
(the file routes.json is depending on hello being defined)
As of Mojito 0.5.2, YML is supported again. 0.5.1 and 0.5.0 do not support it.
We don't have archetypes with yaml, you will have to transform the files manually and renaming them. The good news, a more flexible archetypes infrastructure is on the making.
You should be ok with that configuration you pasted in the question, just use the latest version of mojito (0.5.x)
Related
I want to know how I can use variable syntax inside config-repo yml files.
For example, there is a config-repo which has files like,
- foo.yml
- foo_develop.yml
- foo_production.yml
and inside foo.yml, I want to implement environment variables like,
log:
active: true
file:
auditLogFile: ${HOME}/log/audit.log
But above syntax prints out
{
log:
active: true,
file: {
auditLogFile: '${HOME}/log/audit.log',
},
}
Is something wrong with syntax above? or is it impossible to use env variables inside yml file?
I'm running gradle-swagger-generator-plugin GenerateSwaggerCode task on an input yaml that contains a $refs to another file. Gradle build cache is enabled.
Task output is loaded FROM-CACHE when changes are done the referenced file.
I'm looking for a way to configure the plugin to invalidate the cache and rerun generation if changes are done in ref files.
task definition:
swaggerSources {
myApi {
inputFile = file('./api.yaml')
code {
language = 'spring'
configFile = file('./swagger-config.json')
}
}
}
api.yaml:
swagger: '2.0'
info:
title: My api
version: 1.0.0
host: localhost
definitions:
MyDef:
$ref: './another.yaml#/definitions/MyDef'
swagger.generator version : 2.18.2
swagger-codegen version: 2.4.18
gradle version: 6.8.3
Specifying code.inputs.files in the plugin config seems to fix the problem.
https://github.com/int128/gradle-swagger-generator-plugin/issues/144
I am using an mocha.opts file to configure my tests in VS Code.
DeprecationWarning: Configuration via mocha.opts is DEPRECATED and will be removed from a future version of Mocha. Use RC files or package.json instead.
I am unable to run my tests now and would like to migrate to a mocharc file.
I don't mind the mocharc format being yaml or json.
The mocha documentation is lengthy and doesn't provide migration examples.
Q1: How to do that, are there any examples?
EDIT:
I have found this: https://github.com/mochajs/mocha/blob/master/example/config/.mocharc.yml
Which is an example of a .mocharc.yaml config containing all possible fields.
Q2: What about env vars, I could set them in mocha.opts, how to do that in the .mocharc?
EDITED
A1 : All of thats. mocha document has been seem pretty unkind ..
it seem like file key on yml format can be array field in js, json format. example
// in .mocharc.yml
file:
- '/path/to/some/file'
- '/path/to/some/other/file'
should be
...
file : [
'/path/to/some/file',
'/path/to/some/other/file'
]
A1. you can choose many formats like json, js, yml etc.
when ur mocha opt file is
---ui tdd
--r ts-node/register
--r tsconfig-paths/register
can be changed to mocharc.json like this
{
"require" : [
"ts-node/register",
"tsconfig-paths/register"
],
"package": "./package.json",
"ui": "tdd"
}
A2. this thread maybe help you
github mocha env var setting link
I think it is better setting on package.json, not in mocha file.
but you can specify env vars with require args like this
// In .mocharc.json
{
"require" : [
"ts-node/register",
"tsconfig-paths/register",
"test/mocha.env"
],
"package": "./package.json",
"ui": "tdd"
}
// In mocha.env.ts or mocha.env.js
process.env.NODE_ENV = 'test'
I'm using Laravel 5.4 and Laravel Mix to output SASS files.
In my font definitions I'm configuring them so that when the CSS is output it will point to files such as public/assets/fnt/font-name/filename.ext but the processor changes the output so that it will instead point to public/fonts/filename.ext. Is there a way to stop it from changing the output paths?
It makes little sense to me that it would do something like this by default.
Edit
I've seen that the defaults they're using in Mix are the culprit:
module.exports.module = {
rules: [
// ...
{
test: /\.(woff2?|ttf|eot|svg|otf)$/,
loader: 'file-loader',
options: {
name: 'fonts/[name].[ext]?[hash]',
publicPath: '/'
}
}
]
};
I've tried using null-loader instead of file-loader but instead it causes it to fail because it can't find the files in node_modules which is not where it should be looking in the first place.
Removing the rule in question results in a flood of errors from trying to open and evaluate the font files in question:
error in ./public/assets/fnt/fanfare-jf/fanfare-jf.ttf
Module parse failed: DIRECTORY\public\assets\fnt\fanfare-jf\fanfare-jf.ttf Unexpected character '' (1:0)
You may need an appropriate loader to handle this file type.
(Source code omitted for this binary file)
# ./~/css-loader!./~/postcss-loader!./~/resolve-url-loader!./~/sass-loader?sourceMap&precision=8!./resources/assets/sass/app.scss 6:2525-2590
# ./resources/assets/sass/app.scss
# multi ./resources/assets/js/app.js ./resources/assets/sass/app.scss
I can at least add emitFiles: false to options to prevent it from making copies of the file, but the paths are still being altered.
I ended up with the following configuration to at least get it to a working state.
let assetDir = 'assets/build';
mix.config.fileLoaderDirs.fonts = `${assetDir}/${mix.config.fileLoaderDirs.fonts}`;
mix.config.fileLoaderDirs.images = `${assetDir}/${mix.config.fileLoaderDirs.images}`;
mix.sass('resources/sass/app.scss', `public/${assetDir}/css`)
.js('resources/js/app.js', `public/${assetDir}/js`);
Updated:
In newer versions this has been made customizable via mix.options() and can be adjusted as below:
let assetDir = 'assets/build';
mix.options({
fileLoaderDirs: {
images: `${assetDir}/img`,
fonts: `${assetDir}/fonts`
}
});
// adjust build commands accordingly, for example:
mix.js('resources/js/app.js', `public/${assetDir}/js`);
The output you got is the intended behaviour due to your configuration.
You are using this configuration to load the file:
options: {
name: 'fonts/[name].[ext]?[hash]',
publicPath: '/'
}
Which says use the publicPath as public and create a file with the name fonts/[name].[ext]?[hash] and webpack knows about what these symbols '/', '.', '?' in the name do.
It just looks for the fonts directory and if there is no any fonts directory it creates a new one and place the files into that directory.
So, you need to use this configuration for your folder structure:
options: {
name: 'assets/fnt/font-name/[name].[ext]?[hash]',
publicPath: '/'
}
This should work for your configuration.
More on file-loader configuration:
https://github.com/webpack-contrib/file-loader#filename-templates
Edit:
Since Laravel Mix uses Webpack in it's background and Webpack doesn't have any knowledge of the fonts file when there is no any appropriate loader added to the configuration. So, the error:
Module parse failed: DIRECTORY\public\assets\fnt\fanfare-jf\fanfare-jf.ttf Unexpected character '' (1:0)
You may need an appropriate loader to handle this file type.
is occurred.
You need to tell the Webpack to load the fonts to your desired directory and the fonts linked in your SASS file will be linked by the Webpack without any more configurations.
I'm trying to script out our entire installation process of new Symfony 2.1 projects including adding and configuring all our bundles and their dependencies. The end result should be one command that sets up everything so the developer is both forced into our best practices setup, and does not have to spend time on this.
So far this is fairly successful since it is now possible to go from 0 to fully installed CMS in about an hour (mostly due to composer installs). You can see the result here: https://github.com/Kunstmaan/KunstmaanSandbox/blob/feature/update-to-2.1/README.md
The next fase of this project is modifying the Symfony config YAML files. But here I'm stuck.
For the parameters.yml I did this with a ruby script, here is the relevant extract, the full script can be found here: https://github.com/Kunstmaan/KunstmaanSandbox/blob/feature/update-to-2.1/app/Resources/docs/scripts/sandboxinstaller.rb
parametersymlpath = ARGV[1]
projectname = ARGV[2]
parametersyml = YAML.load_file(parametersymlpath)
params = parametersyml["parameters"]
params["searchport"] = 9200
params["searchindexname"] = projectname
params["sentry.dsn"] = "https://XXXXXXXX:XXXXXXXX#app.getsentry.com/XXXX"
params["cdnpath"] = ""
params["requiredlocales"] = "nl|fr|de|en"
params["defaultlocale"] = "nl"
params["websitetitle"] = projectname.capitalize
File.open(parametersymlpath, 'w') {|f| f.write(YAML.dump(parametersyml)) }
So far so good, but the same type of script fails on the config.yml due to these lines:
imports:
- { resource: #KunstmaanMediaBundle/Resources/config/config.yml }
- { resource: #KunstmaanAdminBundle/Resources/config/config.yml }
- { resource: #KunstmaanFormBundle/Resources/config/config.yml }
- { resource: #KunstmaanSearchBundle/Resources/config/config.yml }
- { resource: #KunstmaanAdminListBundle/Resources/config/config.yml }
The # is a reserved character according to the YAML spec and Ruby throws an error.
So I switched to php and the Symfony yaml component since at this point in the install there is a full symfony install and i came up with this standalone command: https://gist.github.com/3526251
But when reading and dumping the config.yml file the lines above for example would turn into
imports:
-
resource: #KunstmaanMediaBundle/Resources/config/config.yml
-
resource: #KunstmaanAdminBundle/Resources/config/config.yml
-
resource: #KunstmaanFormBundle/Resources/config/config.yml
-
resource: #KunstmaanSearchBundle/Resources/config/config.yml
-
resource: #KunstmaanAdminListBundle/Resources/config/config.yml
Which looks like crap and i'm not entirely sure this will even work.
So at this point i'm looking at moving the fully modified config.yml files to the install script and just overwriting the originals. I would rather not go there, since it will take constant maintenance if something changes in the symfony-standard project.
I'm wondering if there is another way?
These two forms are semantically equivalent. They are called the Inline and Indented Blocks, respectively.