Ghost/test/unit/shared/config/index_spec.js

173 lines
6.3 KiB
JavaScript
Raw Normal View History

const should = require('should');
const path = require('path');
const rewire = require('rewire');
const _ = require('lodash');
const configUtils = require('../../../utils/configUtils');
describe('Config', function () {
before(function () {
configUtils.restore();
});
afterEach(function () {
configUtils.restore();
});
describe('hierarchy of config channels', function () {
let originalEnv;
let originalArgv;
let customConfig;
let config;
beforeEach(function () {
originalEnv = _.clone(process.env);
originalArgv = _.clone(process.argv);
config = rewire('../../../../core/shared/config');
// we manually call `loadConf` in the tests and we need to ensure that the minimum
// required config properties are available
process.env.paths__contentPath = 'content/';
});
afterEach(function () {
process.env = originalEnv;
process.argv = originalArgv;
});
it('env parameter is stronger than file', function () {
process.env.database__client = 'test';
customConfig = config.loadNconf({
baseConfigPath: path.join(__dirname, '../../../utils/fixtures/config'),
customConfigPath: path.join(__dirname, '../../../utils/fixtures/config')
});
customConfig.get('database:client').should.eql('test');
});
it('argv is stronger than env parameter', function () {
process.env.database__client = 'test';
process.argv[2] = '--database:client=stronger';
customConfig = config.loadNconf({
baseConfigPath: path.join(__dirname, '../../../utils/fixtures/config'),
customConfigPath: path.join(__dirname, '../../../utils/fixtures/config')
});
customConfig.get('database:client').should.eql('stronger');
});
it('argv or env is NOT stronger than overrides', function () {
process.env.paths__corePath = 'try-to-override';
process.argv[2] = '--paths:corePath=try-to-override';
customConfig = config.loadNconf({
baseConfigPath: path.join(__dirname, '../../../utils/fixtures/config'),
customConfigPath: path.join(__dirname, '../../../utils/fixtures/config')
});
customConfig.get('paths:corePath').should.not.containEql('try-to-override');
});
it('overrides is stronger than every other config file', function () {
customConfig = config.loadNconf({
baseConfigPath: path.join(__dirname, '../../../utils/fixtures/config'),
customConfigPath: path.join(__dirname, '../../../utils/fixtures/config')
});
customConfig.get('paths:corePath').should.not.containEql('try-to-override');
customConfig.get('database:client').should.eql('sqlite3');
customConfig.get('database:connection:filename').should.eql('/hehe.db');
customConfig.get('database:debug').should.eql(true);
customConfig.get('url').should.eql('http://localhost:2368');
customConfig.get('logging:level').should.eql('error');
customConfig.get('logging:transports').should.eql(['stdout']);
});
});
Improve bootstrap flow of a Ghost application addresses #1789, #1364 - Moves ./core/server/loader -> ./core/bootstrap. The bootstrap file is only accessed once during startup, and it’s sole job is to ensure a config.js file exists (creating one if it doesn’t) and then validates the contents of the config file. Since this is directly related to the initializing the application is is appropriate to have it in the ./core folder, named bootstrap as that is what it does. This also improves the dependency graph, as now the bootstrap file require’s the ./core/server/config module and is responsible for passing in the validated config file. Whereas before we had ./core/server/config require’ing ./core/server/loader and running its init code and then passing that value back to itself, the flow is now more straight forward of ./core/bootstrap handling initialization and then instatiation of config module - Merges ./core/server/config/paths into ./core/server/config This flow was always confusing me to that some config options were on the config object, and some were on the paths object. This change now incorporates all of the variables previously defined in config/paths directly into the config module, and in extension, the config.js file. This means that you now have the option of deciding at startup where the content directory for ghost should reside. - broke out loader tests in config_spec to bootstrap_spec - updated all relevant files to now use config().paths - moved urlFor and urlForPost function into ./server/config/url.js
2014-01-05 10:40:53 +04:00
describe('Index', function () {
it('should have exactly the right keys', function () {
const pathConfig = configUtils.config.get('paths');
// This will fail if there are any extra keys
pathConfig.should.have.keys(
'appRoot',
'internalAdaptersPath',
'contentPath',
'corePath',
'internalAppPath',
'adminViews',
'helperTemplates',
'clientAssets'
);
});
it('should have the correct values for each key', function () {
const pathConfig = configUtils.config.get('paths');
const appRoot = path.resolve(__dirname, '../../../../');
pathConfig.should.have.property('appRoot', appRoot);
});
it('should allow specific properties to be user defined', function () {
const contentPath = path.join(configUtils.config.get('paths').appRoot, 'otherContent', '/');
Improve bootstrap flow of a Ghost application addresses #1789, #1364 - Moves ./core/server/loader -> ./core/bootstrap. The bootstrap file is only accessed once during startup, and it’s sole job is to ensure a config.js file exists (creating one if it doesn’t) and then validates the contents of the config file. Since this is directly related to the initializing the application is is appropriate to have it in the ./core folder, named bootstrap as that is what it does. This also improves the dependency graph, as now the bootstrap file require’s the ./core/server/config module and is responsible for passing in the validated config file. Whereas before we had ./core/server/config require’ing ./core/server/loader and running its init code and then passing that value back to itself, the flow is now more straight forward of ./core/bootstrap handling initialization and then instatiation of config module - Merges ./core/server/config/paths into ./core/server/config This flow was always confusing me to that some config options were on the config object, and some were on the paths object. This change now incorporates all of the variables previously defined in config/paths directly into the config module, and in extension, the config.js file. This means that you now have the option of deciding at startup where the content directory for ghost should reside. - broke out loader tests in config_spec to bootstrap_spec - updated all relevant files to now use config().paths - moved urlFor and urlForPost function into ./server/config/url.js
2014-01-05 10:40:53 +04:00
configUtils.set('paths:contentPath', contentPath);
configUtils.config.get('paths').should.have.property('contentPath', contentPath);
configUtils.config.getContentPath('images').should.eql(contentPath + 'images/');
});
});
describe('Storage', function () {
it('should default to local-file-store', function () {
configUtils.config.get('paths').should.have.property('internalAdaptersPath', path.join(configUtils.config.get('paths').corePath, '/server/adapters/'));
😱 🎨 Refactor storage adapter (#8229) refs #7687 There are four main changes in this PR: we have outsourced the base storage adapter to npm, because for storage developers it's annoying to inherit from a script within Ghost we hacked theme storage handling into the default local storage adapter - this was reverted, instead we have added a static theme storage here use classes instead of prototyping optimise the storage adapter in general - everything is explained in each commit ---- * rename local-file-store to LocalFileStorage I would like to keep the name pattern i have used for scheduling. If a file is a class, the file name reflects the class name. We can discuss this, if concerns are raised. * Transform LocalFileStorage to class and inherit from new base - inherit from npm ghost-storage-base - rewrite to class - no further refactoring, happens later * Rename core/test/unit/storage/local-file-store_spec.js -> core/test/unit/storage/LocalFileStorage_spec.js * Fix wrong require in core/test/unit/storage/LocalFileStorage_spec.js * remove base storage and test - see https://github.com/kirrg001/Ghost-Storage-Base - the test has moved to this repo as well * Use npm ghost-storage-base in storage/index.js * remove the concept of getStorage('themes') This concept was added when we added themes as a feature. Back then, we have changed the local storage adapter to support images and themes. This has added some hacks into the local storage adapters. We want to revert this change and add a simple static theme storage. Will adapt the api/themes layer in the next commits. * Revert LocalFileStorage - revert serve - revert delete * add storagePath as property to LocalFileStorage - define one property which holds the storage path - could be considered to pass from outside, but found that not helpful, as other storage adapters do not need this property - IMPORTANT: save has no longer a targetDir option, because this was used to pass the alternative theme storage path - IMPORTANT: exists has now an alternative targetDir, this makes sense, because - you can either ask the storage exists('my-file') and it will look in the base storage path - or you pass a specific path where to look exists('my-file', /path/to/dir) * LocalFileStorage: get rid of store pattern - getUniqueFileName(THIS) - this doesn't make sense, instances always have access to this by default * Add static theme storage - inherits from the local file storage, because they both operate on the file system - IMPORTANT: added a TODO to consider a merge of themes/loader and themes/storage - but will be definitely not part of this PR * Use new static theme storage in api/themes - storage functions are simplified! * Add https://github.com/kirrg001/Ghost-Storage-Base as dependency - tarball for now, as i am still testing - will release if PR review get's accepted * Adapt tests and jscs/jshint * 🐛 fix storage.read in favicon utility - wrong implementation of error handling * 🎨 optimise error messages for custom storage adapter errors * little renaming in the storage utlity - purpose is to have access to the custom storage instance and to the custom storage class - see next commit why * optimise instanceof base storage - instanceof is always tricky in javascript - if multiple modules exist, it can happen that instanceof is false * fix getTargetDir - the importer uses the `targetDir` option to ensure that images land in the correct folder * ghost-storage-base@0.0.1 package.json dependency
2017-04-05 17:10:34 +03:00
configUtils.config.get('storage').should.have.property('active', 'LocalFileStorage');
});
it('no effect: setting a custom active storage as string', function () {
configUtils.set({
storage: {
active: 's3',
s3: {}
}
});
configUtils.config.get('storage').should.have.property('active', 's3');
configUtils.config.get('storage').should.have.property('s3', {});
});
it('able to set storage for themes (but not officially supported!)', function () {
configUtils.set({
storage: {
active: {
images: 'local-file-store',
themes: 's3'
}
}
});
configUtils.config.get('storage').should.have.property('active', {
images: 'local-file-store',
themes: 's3'
});
});
it('should allow setting a custom active storage as object', function () {
configUtils.set({
storage: {
active: {
images: 's2',
themes: 'local-file-store'
}
}
});
configUtils.config.get('storage').should.have.property('active', {
images: 's2',
themes: 'local-file-store'
});
});
});
});