32 votes

Yeoman de Workflow et l'Intégration avec les Scripts principaux

Donc, j'ai été en anticipant Yeoman et il est déjà sorti depuis une semaine maintenant. Mais après avoir réussi à l'installer, j'ai été confondu dans le flux de travail et la mise en œuvre avec backend script (API).

Scénario 1

Donc, disons que je n'ai pas besoin de tous ces brillants BBB/Ember/Angulaire des trucs et de les utiliser Yeoman juste pour jQuery/H5BP/Modernizr soutenu avec Codeigniter ou Sinatra/Rails. Depuis yeoman server n'est pas nativement en charge le PHP (je n'ai pas essayé Sinatra/Rails), je me dis que le flux de travail est:

  • Développement Front End avec Yeoman
  • Après c'est fini, ne yeoman build , puis utilisez la fonction intégrée dist le dossier comme une base pour développer backend (et probablement copier l' dist le dossier vers un autre dossier pour le backend de mise en œuvre (disons public le dossier)
  • Si je dois changer de CSS/JS, utilisez yeoman encore, de construire et de copier l' dist le dossier d' public de nouveau. Ainsi de suite...

Mais à l'aide de flux de travail, cela signifie que la structure de répertoire sera quelque chose comme

cool-app/
--app/
  --yeoman development stuff
--test/
  --yeoman development stuff
--dist/
  --yeoman built stuff
.dotfiles
package.json
Gruntfile.js

C'est bien joli, mais un peu différent avec la CodeIgniter / Rails de la structure de répertoire. Ne pas mentionner il ya le nom de différence (est-ce configurables dans Yeoman?), c'est assez difficile d'imaginer un bon flux de travail de développement Front-End et Back-End d'un seul coup, sauf en utilisant le résultat comme une base pour le backend.

Scénario 2

BBB/Ember/Angulaire. Franchement j'ai été tout simplement de le tester d'autres choses, de sorte que toute les astuces à mettre en œuvre avec backend code est la bienvenue! Mais pour tout ce que je sais, yeoman pouvez générer les fichiers nécessaires pour ceux qui cadre à l'intérieur de dossier app, donc je figure, la solution du premier scénario sera un peu de résoudre le problème pour le scénario 2

Merci beaucoup!

37voto

Sanford Redlich Points 406

J'aime utiliser cette structure:

rails-app/
--app/
  --views/
    --js/
      --app/
      --test/
      --Gruntfile.js
--public

Voici comment je l'ai installé:

  • rails les rails-app
  • cd rails-app/app/views
  • mkdir js
  • cd js
  • yeoman init braise

Puis modifier Gruntfile.js pour changer de sortie": 'dist'" à la sortie": '../../../public""

Après cela, "yeoman construire" ou "yeoman construire:dist" sera de sortie pour les Rails /dossier public.

Au cours de dev, vous pouvez toujours utiliser "yeoman serveur" pour exécuter yeoman, le mode de développement, de sorte que toute modification sera automatiquement visible dans le navigateur.

Yeoman est grand!

3voto

SpiritMachine Points 972

Sanford, en réponse va travailler pour Sinatra, bien sûr, mais il est un peu une autre solution qui peut être utilisé de sorte que vous n'avez pas de problème "yeoman construire" pour s'exécuter en mode de développement.

En Sinatra, le dossier public est configurable, vous pouvez configurer le bloc qui ressemble à ceci:

configure do
    set :public_folder, ENV['RACK_ENV'] == 'production' ? 'dist' : 'app'  
end

Ensuite, utilisez vos routes, comme ceci:

get '/' do    
    send_file File.join(settings.public_folder, 'index.html')  
end

C'est en supposant que "yeoman init" a été exécuté dans le dossier racine de la Sinatra application.

Tous vous avez faire est de vous assurer que vous avez exécuté "yeoman construire" avant de les déployer dans un environnement de production, et le yeoman-optimisation de contenu sera utilisé.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X