2016-07-02 11 views
5

Sto sviluppando un componente React e desidero pubblicarlo su npm, ma non sono riuscito a trovare alcuna best practice su come distribuire le risorse statiche (come css e immagini) insieme al componente. Bene, ovviamente tutte le fonti dovrebbero essere trascritte in plain js e plain css. Nel caso di js, tutto è semplice: l'utente lo richiederà semplicemente con qualsiasi pacchetto che sta utilizzando. Ma nel caso del css è complicato. Non voglio usare gli stili in linea dal momento che voglio che il componente sia facilmente personalizzabile (per override di css). Quindi, suppongo che l'unico modo è chiedere all'utente di copiare il file css da node_modules a dove ne ha bisogno (o importarlo con SASS o qualsiasi altro preprocessore). Ma cosa succede se il mio file css ha riferimenti ad altre risorse statiche (come immagini, caratteri, ecc.)? I percorsi saranno completamente incasinati credo. Quindi, sono interessato a qual è il modo giusto per farlo? Come rendere più facile per l'utente consumare e come evitare le insidie ​​più comuni?Come pubblicare il componente React con asset statici su npm?

+0

Forse dovresti mostrarti produzione/dist config webpack. – MacKentoch

+0

@MacKentoch Non ho una configurazione di webpack per questo poiché non penso che npm sia il posto giusto per le versioni bundled/minified. Quello che faccio è traspare jsx in ES5. – alexb

risposta

0

Questa è davvero una bella domanda. Non sono sicuro che la mia risposta sia ciò che ti aspetti (sarà più filosofico che tecnico), ma penso che sia un buon punto di partenza.

Prima di tutto, penso che non ci sia un "modo giusto" per farlo. Immagina un team (può essere un team di una sola persona) che gestisce un pacchetto, il modo in cui il nome delle cose è il modo che ha senso per loro, e questa è la "strada giusta". Quindi, non esiste uno "standard" per nominare le cose, nominare le cose nel modo in cui si pensa sia corretto e si è pronti per andare.

Ora, IMHO, chi utilizzerà il pacchetto dovrebbe preoccuparsi di come utilizzarlo, non tu. Dal momento che la persona può fare delle scelte su ciò che vuole o meno usare dal tuo pacchetto, e su come vogliono usarlo.

Ad esempio, se si utilizza webpack, siamo in grado di utilizzare url-loader, che risolverà il problema di URL a noi.

Se non si utilizza il webpack, ciò che si può fare è fornire una documentazione coerente sul pacchetto e su come usarlo. I tuoi utenti seguiranno questo, usando gli strumenti che vogliono. Se i tuoi utenti vogliono usare grep e sed nel loro flusso di lavoro, va bene, dal momento che ne hanno il controllo.

Inoltre, ora si parla specificamente di CSS, se si desidera fornire stili che utilizzino le immagini, è possibile provare a utilizzare un preprocessore o qualcosa del genere e consentire all'utente di personalizzare alcune variabili per impostare il percorso delle cose. Ad esempio, immagina di dire assets-path, usando SASS, il tuo utente deve solo aggiungere $assets-path: '/path/to/assets/' e compilare il CSS.

Ogni volta che uso un pacchetto, tendo a pensare come "ok, ci sono molte cose lì, non ho bisogno di usarle tutte, userò le cose che voglio", e se Vorrei usare il tuo pacchetto e so che ci saranno file CSS, proverei a trovare un buon set di strumenti per aiutarmi.

Se si desidera seguire alcuni "standard", provare a controllare i progetti di reazione più popolari su Github, ma, come ho detto prima, il modo in cui denominano le cose è il modo che ha senso per loro. Potrebbe non avere senso per te! :)

Spero che aiuti!

Problemi correlati